Acknowledgements
This communication is in response to applicant’s response filed on 03/07/2025.
Claims 1, 3-4, 7, 11-13, and 18 have been amended.
Claims 1-18 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 1-3, filed 03/07/2025, with respect to the rejection(s) of claim(s) 1-4, 7, 9-13, and 15-18 under Claim Rejections - 35 USC § 102 regarding claim 1, 8, and 18 that Makhotin (US 20150127529) does not teach, disclose, or suggest “identify an application based on the application identifier; authenticate with the one or more application servers using the user credential; obtain transaction information for a transaction performed by the user via the POS system” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, a new Claim Rejections - 35 USC § 103 has been added directed to claims 1-4, 7, 9-13, and 15-18 in view of Osborn (US 20210201324).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7, 9-13, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Makhotin (US 20150127529) in view of Osborn (US 20210201324).
Regarding Claims 1, 11, and 18, Makhotin teaches trigger the transceiver to interrogate the one or more tags to obtain a data string indicative of an application identifier and a user credential (Paragraphs 0118 and 0070-0073 teach an access device may communicate with an application linker module of the portable communication device to obtain a list of available payment applications on the portable communication device; for example, the access device may send a request for available payment applications stored on the portable communication device to the portable communication device; the request may include any relevant information to allow the portable communication device determine that the access device is requesting available payment applications and that an application linker module is configured to respond to the request; the access device may communicate with the portable communication device to obtain application information (e.g., application identifier, consumer account information, payment credentials, cardholder verification results, etc.) from the one or more payment applications; the communication module of the access device may include any code, application, or any other software module configured to interface with an antenna or other communications hardware of the access device to communicate with a portable communication device; the communication module and an associated data processor may be configured to identify the presence of a portable communication device when within communication range); generate an instruction to submit the transaction information to an account associated with the user credential, the instruction being formatted in accordance with the one or more APIs of the one or more application servers corresponding to the identified application (Paragraphs 0111 and 0080 teach after the access device receives the payment account identifier or the payment device identifier, the access device or the merchant computer in communication with the access device generates an authorization request message for the transaction; the data included in the authorization request message may include data obtained from a portable communication device as well as other data related to the transaction, the payment account holder, or the merchant, such as one or more of a payment account number, the payment device expiration date, a currency code, the sale amount, a merchant transaction stamp, the acceptor city, the acceptor state/country, etc.; the transaction authorization module may include any application, code, and/or any other software configured to initiate payment transaction processing; for example, the transaction authorization module may receive payment information from a portable communication device and may initiate transaction using payment information obtained from the selected payment application; the transaction authorization module may generate an authorization request message for the transaction); and transmit the instruction to the one or more application servers (Paragraphs 0138-0140, 112, and 114 teach the merchant computer may then send the authorization request message to an acquirer computer and/or payment processing network associated with the account and/or payment credentials included in the authorization request message; the payment processing network computer may receive the authorization request message and determine an account issuer associated with the authorization request message; the merchant computer (or access device) transmits the authorization request message to the acquirer computer, which then transmits the authorization request to a payment processing network; the payment processing network transmits the authorization request message to an issuer computer).
However, Makhotin does not explicitly teach identify an application based on the application identifier; authenticate with the one or more application servers using the user credential; obtain transaction information for a transaction performed by the user via the POS system.
Osborn from same or similar field of endeavor teaches identify an application based on the application identifier (Paragraphs 0076 and 0019 teach a communication between a mobile device and a contactless card is initiated, where the communication utilizes a card reader and where the communication is based on an NFC protocol; the communication is condition about the first-level comparison resulting in a match, and in various embodiments, instead of sending the first application credential for comparison at the server, the comparison is done between the mobile device and the contactless card, where the stored second credential is stored in a memory of the contactless card; the comparison with respect to the user credential is omitted, and a tap of the contactless card on the mobile device initiates a prompt to select which application requires authentication, e.g. access application, and the NFC communication between the contactless card and the mobile device commences to initiate online verification or authentication of a user using a payment protocol consistent with an EMV standard, but for purposes that include a verification or authentication for purposes other than merely completing a sale or purchase; a user taps the contactless card to the mobile device to cause the contactless card to generate and transmit encrypted data (e.g., the encrypted customer ID); the contactless card may comprise one or more chip, such as a radio frequency identification (RFID) chip, configured to communicate with the mobile devices via NFC, the EMV standard, or other short-range protocols in wireless communication); authenticate with the one or more application servers using the user credential (Paragraphs 0078-0079 teaches the contactless card may transmit the encrypted data to the account application of the mobile device, e.g., using NFC; the contactless card further includes an indication of the counter value along with the encrypted data; the account application of the mobile device may transmit the data received from the contactless card to the management application of the server; the management application decrypts the encrypted data received from the contactless card via the mobile device using the diversified key and a cryptographic algorithm; doing so may yield at least the customer identifier; by yielding the customer identifier, the management application may validate the data received from the contactless card; for example, the management application may compare the customer identifier to a customer identifier for the associated account in the account data, and validate the data based on a match; doing so may cause the management application to transmit an indication of the validation to the mobile device); obtain transaction information for a transaction performed by the user via the POS system (Paragraph 0080 teaches responsive to the decryption and validation, the management application can provide access to one or more loyalty point accounts and can permit redemptions of one or more loyalty points associated therewith, including loyalty points associated with retailer).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Makhotin to incorporate the teachings of Wilson for the instruction to indicate user classification data indicating one or more of an expense category, a reference identifier, or comment data for at least a portion of the transaction information.
There is motivation to combine Wilson into Makhotin because the present disclosure provide one or more benefits in terms of verifying a user and completing a transaction, such as a payment transaction, including taking advantage of enhanced security offered by dynamic authentication techniques, e.g. online techniques, while also utilizing a barcode to complete a transaction (which offers both convenience and additional security). In various embodiments, utilizing the online technique enhances the efficiency of a computer device, e.g. a mobile phone, by providing a single method for authenticating or verifying a user across one or more applications, even if the one or more applications are distinct in their purpose, e.g. a transportation application in relation to an entertainment application. Accordingly, in various embodiments, an authorization protocol can be used to efficiently and more securely authenticate a user across different applications and purposes, and then utilize a barcode generated as a result of the verification to complete a transaction associated with one or more of the different applications, including transactions and operations that may or may not involve making a payment (Osborn Paragraph 0018).
Regarding Claim 1, Makhotin teaches a point-of-sale (POS) system comprising: a user interface; a transceiver configured to interrogate one or more tags; a memory storing a plurality of applications having respective identifiers, the applications being configured to interface with one or more application servers via respective one or more application programming interfaces (APIs); a controller operatively connected to the user interface and the transceiver and configured to perform operations (Paragraphs 0071 and 0074 teach the access device may include a processor and a memory including a communication module, an application selection module, and a transaction authorization module; although not shown in FIG. 2, the modules may be contained on a computer-readable medium coupled to the processor, the computer-readable medium comprising code, executable by the processor, for performing the functionality described herein; the communication module and an associated data processor may be configured to send and receive a number of different communications and messages with a portable communication device; for example, the communication module and an associated data processor may be configured to send a request for available payment applications to the portable communication device which may be processed by an application linker module, mobile application, a secure element, or any module of the portable communication device configured to communicate with the access device).
Regarding Claim 11, Makhotin teaches a computer-implemented method for point-of-sale (POS) third-party application integration implemented at a point of sale system that includes (i) a user interface; (ii) a transceiver configured to interrogate one or more tags; (iii) a memory storing a plurality of applications having respective identifiers, the applications being configured to interface with one or more application servers via respective one or more application programming interfaces (APIs); and (iv) a controller operatively connected to the user interface and the transceiver (Paragraphs 0116-0117 teach FIG. 4 shows an exemplary flow diagram of a method of initiating a transaction between a portable communication device and an access device, according to an exemplary embodiment of the invention; before the method shown in FIG. 4, a user may initiate a transaction by presenting a portable communication device to an access device; as described above in reference to FIGS. 2-3, the portable communication device may comprise multiple mobile payment applications associated with multiple application identifiers; the portable communication device may comprise an application linker module that manages, configures, and communicates the application identifiers to the access device; when the portable communication device is within communication range with the access device, the access device may sense the presence of the portable communication device).
Regarding Claim 18, Makhotin teaches a point-of-sale (POS) system comprising: a user interface including a display unit; a memory storing a plurality of applications having respective identifiers, the applications being configured to interface with one or more application servers via respective one or more application programming interfaces (APIs); a controller operatively connected to the user interface (Paragraphs 0146 and 0074 teach the subsystems shown in FIG. 5 are interconnected via a system bus; additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others are shown; peripherals and input/output (I/O) devices, which couple to I/O controller (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port; for example, serial port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner; the interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems; the communication module and an associated data processor may be configured to send and receive a number of different communications and messages with a portable communication device; for example, the communication module and an associated data processor may be configured to send a request for available payment applications to the portable communication device which may be processed by an application linker module, mobile application, a secure element, or any module of the portable communication device configured to communicate with the access device).
Regarding Claim 2, the combination of Makhotin and Osborn teaches all the limitations of claim 1 above; and Makhotin further teaches wherein: the user interface is configured to receive a user identifier associated with a user; and the instruction includes the user identifier (Paragraphs 0066 teaches the application linker module may send the list of available payment applications to the access device for selection of one of the available payment applications; however, certain access devices may only be configured to receive and process particular types of information associated with particular payment applications; for example, if the access device is only configured to process transactions using a certain payment processing network (e.g., VisaNet™), the access device may not process transaction information originating from payment applications that are only configured to provide information in the format for processing with a different payment processing network (e.g., MasterCard™)).
Regarding Claims 3 and 12, the combination of Makhotin and Osborn teaches all the limitations of claims 1 and 11 above; and Makhotin further teaches wherein the controller is configured to: generate the instruction responsive to the authentication (Paragraph 0080 teaches the transaction authorization module may include any application, code, and/or any other software configured to initiate payment transaction processing; for example, the transaction authorization module may receive payment information from a portable communication device and may initiate transaction using payment information obtained from the selected payment application; the transaction authorization module may generate an authorization request message for the transaction or may pass the payment information to a merchant computer for generation of an authorization request message for payment network processing).
Regarding Claims 4 and 13, the combination of Makhotin and Osborn teaches all the limitations of claims 1 and 11 above; and Makhotin further teaches wherein: the user interface includes a display unit; and responsive to the authentication, the controller is configured to: receive, from the one or more application servers, classification data for the account associated with the user credential (Paragraphs 0141-0142 teach the issuer computer receives the authorization request message and determines whether the transaction should be authorized and may determine the account associated with the authorization request message, compare a value or credit available in the account to the transaction amount, perform any number of fraud checks or risk analysis processes, and/or perform any other relevant actions to determine an appropriate authorization decision; the issuer computer may determine an authorization decision and may generate an authorization response message including the authorization decision; the issuer computer may send the authorization response message to the payment processing network computer for completion and processing of the transaction); and present, via the display unit, the classification data (Paragraphs 0143-0144 and 0114 teach the payment processing network computer may receive the authorization response message, log the authorization decision for settlement and clearance purposes, and send the authorization response message to the acquirer computer for reporting to the merchant computer and/or access device; the payment processing network computer may also send a notification to the portable communication device including the authorization decision; the merchant computer receives the authorization response message and completes the transaction based on the authorization decision of the authorization response message; for example, the merchant may provide a good or service if the authorization response message includes an indication of an accepted transaction and may decline to provide a good or service when receiving a declined authorization decision; the merchant computer may provide the authorization response message to the access device; the authorization response message is routed back to the merchant computer; the authorization response may be displayed by the access device (e.g., a POS terminal)).
Regarding Claims 7 and 15, the combination of Makhotin and Osborn teaches all the limitations of claims 1 and 11 above; and Makhotin further teaches wherein: the user credential is a first user credential (Paragraphs 0066 teaches the application linker module may send the list of available payment applications to the access device for selection of one of the available payment applications; certain access devices may only be configured to receive and process particular types of information associated with particular payment applications; for example, if the access device is only configured to process transactions using a certain payment processing network (e.g., VisaNet™), the access device may not process transaction information originating from payment applications that are only configured to provide information in the format for processing with a different payment processing network (e.g., MasterCard™)); and to authenticate with the one or more application servers, the controller is configured to: authenticate with one or more intermediate servers using the first user credential (Paragraphs 0067, 0071, and 0077-0079 teach the application linker may provide a list of available application identifiers along with priority information to an access device during transaction processing and may determine one or more payment applications associated with the application identifier, may select a preferred payment application, and may route the request for the payment information to the appropriate payment application; the access device may include a processor and a memory including a communication module, an application selection module; the application selection module may determine supported applications from the list of available payment applications through any suitable manner; once the best match of the payment applications is determined, the application selection module may select an application identifier from the supported payment applications by generating and sending a selection message including the selected application identifier to the portable communication device in order to obtain payment information associated with the selected application identifier); obtain, from the one or more intermediate servers, a second user credential for authentication with the one or more application servers (Paragraphs 0041 and 0134-0135 teach if the authentication processing is more rigorous and/or the fraud risk is lower for a particular payment application, the merchant may select the preferred payment application; for example, each application identifier (AID) may have different authentication methods associated with the processor for which it is configured to be used with; the application linker module receives the payment information from the selected payment application associated with the selected application identifier and forwards the payment information to the access device; the communication module of the access device receives the payment information associated with the selected payment application and the payment authorization module of the access device initiates a transaction using the received payment information); and authenticate with the one or more application servers using the second user credential (Paragraphs 0041-0042 and 0136 teach some payment processing networks may use signature authentication, but other payment processing networks may capture an online PIN for account holder verification; the portable communication device may prompt the consumer for the particular authentication and/or validation method associated with the application identifier that is selected by the access device, not necessarily the payment application being used; a particular application identifier may indicate that these payment applications require specific authentication methods (e.g., challenge response, password entry, etc.); depending on what the network associated with the application identifier actually supports, the selected application may request cardholder authentication; the initiation may include any number of functions including completing a cardholder verification using methods associated with the particular application identifier, communicating multiple messages back and forth with the portable communication device to obtain the correct information, cardholder approval, etc., or sending messages back and forth between the other entities within the transaction processing eco-system and the portable communication device as necessary or desired for transaction processing).
Regarding Claims 9 and 16, the combination of Makhotin and Osborn teaches all the limitations of claims 1 and 11 above; and Makhotin further teaches wherein: the POS system is implemented at a personal electronic device (Paragraph 0063 teaches examples of access devices include point of sale (POS) devices, cellular phones, PDAs, personal computers, tablets, handheld specialized readers, and the like); and the user credential includes one or more of a user name, a password or a one-time password (Paragraph 0046 teaches cardholder verification information (e.g., passcode, password, personal identification number (PIN), etc.)).
Regarding Claims 10 and 17, the combination of Makhotin and Osborn teaches all the limitations of claims 1 and 11 above; and Makhotin further teaches wherein: the transceiver is an RFID transceiver (Paragraph 0063 teaches access devices may use means such as radio frequency (RF) readers to interact with the portable communication device through contactless communication); and the one or more tags are one or more RFID tags embedded in a tap card (Paragraphs 0066, 0068, and 0086 teach the secure element may include an application linker module and a plurality of mobile payment applications that are capable of accessing payment information (e.g., an account identifier) securely stored on the secure element; the mobile payment applications may include two or more software modules installed or provisioned on the secure element that are capable of providing payment information stored on the secure element during a transaction; the mobile payment applications may be provisioned on the secure element by any entities within a mobile communication ecosystem; the application linker and an associated data processor may be configured to manage, determine, and communicate a list of application identifiers associated with provisioned or installed payment applications on a secure element as well as the corresponding priorities for the application identifiers).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Makhotin (US 20150127529) in view of Osborn (US 20210201324) in further view of Mell (US 20200320503).
Regarding Claim 5, the combination of Makhotin and Osborn teaches all the limitations of claim 4 above; however, the combination does not teach wherein the controller configured to: classify the transaction information in accordance with the classification data via one or more of machine learning, artificial intelligence, and a neural network.
Mell from same or similar field of endeavor teaches wherein the controller configured to: classify the transaction information in accordance with the classification data via one or more of machine learning, artificial intelligence, and a neural network (Paragraph 0108 teaches the platform server may track the remote transactions of a remote workforce, and may implement trained machine-learned models and algorithms; for instance, the platform server may receive and store data corresponding to the transactions performed by a set of remote workers in a particular role and at a particular organization, and may use the data as training data to generate one or more machine-learned models trained to output deviating and non-deviating transactions; when an Internet purchase or other network transaction performed by a remote worker is determined by the platform server, via trained machine-learned models, to be a deviation from a predicted pattern of remote transactions, the platform server may initiate an interactive session with the remote worker's mobile device; the platform server may maintain one or more data stores to collect and store training data and/or trained models corresponding to the patterns and predictions of remote transactions performed by the remote workforce).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Makhotin and Osborn to incorporate the teachings of Mell for the controller to be configured to: classify the transaction information in accordance with the classification data via one or more of machine learning, artificial intelligence, and a neural network.
There is motivation to combine Mell into the combination of Makhotin and Osborn because using machine learning enables the system to automatically detect deviations from the predicted network-based transactions of the remote workforce (Mell Paragraph 0108).
Claims 6, 8, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Makhotin (US 20150127529) in view of Osborn (US 20210201324) in further view of Wilson (US 20220012734)
Regarding Claims 6 and 14, the combination of Makhotin and Osborn teaches all the limitations of claims 4 and 13 above; however, the combination does not teach wherein: the instruction indicates user classification data indicating one or more of an expense category, a reference identifier, or comment data for at least a portion of the transaction information.
Wilson from same or similar field of endeavor teaches wherein: the instruction indicates user classification data indicating one or more of an expense category, a reference identifier, or comment data for at least a portion of the transaction information (Paragraphs 0807-0808 teach the issuer/agent is operable to receive, from the cardholder, descriptive names of each transaction type, and to include the descriptive names in a record of transactions issued to the cardholder; for example, a cardholder might assign descriptive names based on the type of expense, such as “entertainment” for type 1, “household supplies” for type 2, “home maintenance” for type 3, “work expenses” for type 4, and “other” for type 5; alternatively, the issuer can be operable to assign a transaction type and descriptive name based on characteristics of the transaction, for example the type of vendor or other information, without input from the cardholder; many other transaction types can be used, for example: expense type, budget category, location, currency, project, or person or organization benefiting from the expense).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Makhotin and Osborn to incorporate the teachings of Wilson for the instruction to indicate user classification data indicating one or more of an expense category, a reference identifier, or comment data for at least a portion of the transaction information.
There is motivation to combine Wilson into the combination of Makhotin and Osborn because classifying transaction data improves financial analysis and reporting and strategic decision-making. Assigning correct categories to financial transactions is important because errors on this task can lead to incorrect financial statements, increased audit risk, tax, and other regulatory penalties, misinformed financial decisions, and displeased creditors and investors.
Regarding Claim 8, the combination of Makhotin and Osborn teaches all the limitations of claim 7 above; however, the combination does not teach wherein: the one or more intermediate servers use an open standard for authentication.
Wilson from same or similar field of endeavor teaches wherein: the one or more intermediate servers use an open standard for authentication (Paragraphs 0035-0036 teach some finance compliant SEs with a GP standards compliant operating system employ a security hierarchy in accordance with GP standards for management of contents of the SEs; the security hierarchy comprises a tree of security domains, including an Issuer Security Domain (ISD), having the highest authority and control over the contents and operations in the whole SE; the security hierarchy may also include one or more Supplementary Security Domains (SSDs), each having subsidiary authority and control over a subset of the contents and operations of the ISD; each security domain is implemented using an application which has its own AID; each security domain may have an associated key (typically a symmetric key) with a copy of the key stored in the corresponding security domain application and another copy of the key kept by (or is in the control of)an entity (or agent) with authority over that security domain).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Makhotin and Osborn to incorporate the teachings of Wilson for the one or more intermediate servers to use an open standard for authentication.
There is motivation to combine Wilson into the combination of Makhotin and Osborn because this enables secure interoperability between unique identity systems, web resources, organizations and vendors.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Li et al. (US 20190354980) teaches a payment verification method and apparatus are disclosed. The method includes: if a payment terminal detects that there is valid verification information in a secure storage of the payment terminal, changing, by the payment terminal, a cardholder verification method (CVM) supported by a currently used payment card to “no CVM required”, where the payment card is a preset card or a card selected by a user, and the secure storage of the payment terminal is a trusted storage area in a trusted execution environment (TEE) or a secure storage area in a rich execution environment (REE); and notifying, by the payment terminal, the settlement terminal that the CVM supported by the payment card is “no CVM required”, so that the settlement terminal performs verification on the user and completes a transaction according to “no CVM required.”
Wilson (US 20220012716) teaches an apparatus for a Digital Payment Device (DPD) operable for a digital transaction with a Digital Transaction Device (DTD), the apparatus being operable to provide transaction application identifier information for communication from the DPD to the DTD in a digital transaction, the apparatus including: an application selection module; on the DPD, a Digital Transaction Processing Unit (DTPU) operable to host one or more Personalized Digital Transaction Packages (PDTPs), each PDTP associated with at least one transaction application having a transaction application identifier; the DPD being operable to select at least one hosted PDTP to be operable for a digital transaction with the DTD; wherein the apparatus is operable to receive one or more commands to cause the application selection module to be set with a transaction application identifier for each transaction application associated with the selected at least one PDTP, such that the application selection module is operable to include, in the transaction application identifier information, the transaction application identifier for each transaction application associated with the selected at least one PDTP.
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 COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. 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.
/COURTNEY P JONES/Primary Examiner, Art Unit 3685