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 .
DETAILED ACTION
The following is a Non-Final Office Action in response to communications received July 28, 2025. Claims 6 and 15 have been cancelled. Claims 1, 10, and 19 have been amended. Claims 1-5, 7-14, and 16-20 remain pending and examined.
Response to Amendments and Arguments
As to the rejection of Claims 1-5, 7-14, and 16-20 under 35 U.S.C. § 112, Applicant’s arguments and amendments have been fully considered and are persuasive. The rejection is thereby withdrawn.
As to the rejection of Claims 1-5, 7-14, and 16-20 under 35 U.S.C. § 101, Applicant’s arguments and amendments have been fully considered but are not persuasive. Applicant argues that the present claims are integrated into a practical application. Examiner disagrees. The claims in the instant application include an abstract idea, and when considered as a whole, the claims (independent and dependent) do not integrate the exception into a practical application, and merely add the words “apply it” to the “the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The additional elements do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. And simply relying on a computer to perform routine tasks or calculations more quickly or more accurately is insufficient to render a claim patent eligible. See Alice, 134 S. Ct. at 2359 (“use of a computer to create electronic records, track multiple transactions, and issue simultaneous instructions” is not an inventive concept); Bancorp Servs., L.L.C. v. Sun Life Assur. Co. of Can. (U.S.), 687 F.3d 1266, 1278 (Fed. Cir. 2012) (a computer “employed only for its most basic function . . . does not impose meaningful limits on the scope of those claims”); cf. DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258–59 (Fed. Cir. 2014) (finding a computer-implemented method patent eligible where the claims recite a specific manipulation of a general-purpose computer such that the claims do not rely on a “computer network operating in its normal, expected manner”). As elaborated in the rejection below, using one or more processors is simply “apply it” using generic computer components rather than integrating the judicial exception into a practical application. The rejection is thereby maintained.
As to the rejection of claims 1-5, 7-14, and 16-20 under 35 U.S.C. § 102, Applicant's amendments and arguments have been fully considered but are not persuasive. Applicant argues that Makhdumi does not teach “an actual request for payment that is submitted by a potential payee; instead, there is merely an advertisement and a QR code, and the potential payor must then decide whether or not to purchase the advertised programming, and then, if a decision is made to do so, the potential payor submits the request for payment”. Examiner disagrees. The limitation of an actual request for payment that is submitted by a potential payee is found in Makhdumi at ¶[0078] – “the merchant server may initiate clearance of a batch of authorized transactions. For example, the merchant server may generate a batch data request, e.g., 438, and provide the request, e.g., 439, to a database, e.g., merchant database 404. For example, the merchant server may utilize PHP/SQL commands similar to the examples provided above to query a relational database. In response to the batch data request, the database may provide the requested batch data, e.g., 440. The server may generate a batch clearance request, e.g., 441, using the batch data obtained from the database, and provide, e.g., 442, the batch clearance request to an acquirer server, e.g., 410. For example, the merchant server may provide a HTTP(S) POST message including XML-formatted batch data in the message body for the acquirer server. The acquirer server may generate, e.g., 443, a batch payment request using the obtained batch clearance request, and provide the batch payment request to the pay network server, e.g., 444. The pay network server may parse the batch payment request, and extract the transaction data for each transaction stored in the batch payment request, e.g., 445. The pay network server may store the transaction data, e.g., 446, for each transaction in a database, e.g., pay network database 407. For each extracted transaction, the pay network server may query, e.g., 447-448, a database, e.g., pay network database 407, for an address of an issuer server. For example, the pay network server may utilize PHP/SQL commands similar to the examples provided above. The pay network server may generate an individual payment request, e.g., 449, for each transaction for which it has extracted transaction data, and provide the individual payment request, e.g., 450, to the issuer server, e.g., 408.”. The rejection is thereby maintained as detailed below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5, 7-14, and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-5, 7-14, and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. (Step 1) The claims recite a method, apparatus, and a computer program product. For the purposes of this analysis, representative claim 1 is addressed. (Step 2A, prong 1) Abstract ideas are in bold below, and represents a mental process, as a method of facilitating a payment. Receiving an identification number, retrieving identifying information, transmitting a first message, receiving a second message, validating the request for payment, transferring information associated with the requested amount of the payment, and transmitting a confirmation that requested payment has been completed are all akin to certain methods of organizing human activity.
A method for facilitating a cashless payment, the method being implemented by at least one processor, the method comprising: receiving, by the at least one processor, an identification number that corresponds to a request for payment submitted by a potential payee, the identification number excluding personally identifying information of a potential payor by the at least one processor based on the received identification number by the at least one processor to the potential payor, a first message that includes a request for confirmation that the potential payor intends to make a payment to the potential payee and a request for an amount of the payment; receiving, by the at least one processor from the potential payor, a second message that includes the requested confirmation and the requested amount of the payment; validating, by the at least one processor based on the received second message, the request for payment; transferring, to the potential payee, a cookie that is associated with the requested amount of the payment; and when a confirmation that the requested payment has been completed is received, transmitting, by the at least one processor to the payor, a confirmation that the requested payment has been completed, wherein the identification number that corresponds to the request for payment is received from an entity associated with a Uniform Resource Locator (URL) address accessed by the potential payee in order to submit the request for payment.
(Step 2A prong 2) The additional elements are considered as follows:
“by at least one processor” and “cookie”. These are merely “apply it” these processors are claimed at a high level of generality, it receives the information, performs the abstract idea, and outputs the results. Simply implementing the abstract idea (a known payment exchange practice) on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
(Step 2B) Under Step 2B, the additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception. As discussed with respect to Step 2A prong 2, the claim as a whole merely describes how to generally “apply” the concept of a known payment exchange practice in a computer environment. Thus, even when taken individually and in combination, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claim is ineligible.
The other independent claims contain similar language. Analysis of dependent claims 2-5, 7-9, 11-14, 16-18, and 20 recite details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more. This judicial exception is not integrated into a practical application because the additional elements of “by at least one processor” are all recited at a high level of generality. According to the specification the “processor” is described as generic computer components (see ¶[0041] – “The processor 104 is tangible and non-transitory. As used herein, the term “non-transitory” is to be interpreted not as an eternal characteristic of a state, but as a characteristic of a state that will last for a period of time. The term “non-transitory” specifically disavows fleeting characteristics such as characteristics of a particular carrier wave or signal or other forms that exist only transitorily in any place at any time. The processor 104 is an article of manufacture and/or a machine component. The processor 104 is configured to execute software instructions in order to perform functions as described in the various embodiments herein. The processor 104 may be a general purpose processor or may be part of an application specific integrated circuit (ASIC). The processor 104 may also be a microprocessor, a microcomputer, a processor chip, a controller, a microcontroller, a digital signal processor (DSP), a state machine, or a programmable logic device. The processor 104 may also be a logical circuit, including a programmable gate array (PGA) such as a field programmable gate array (FPGA), or another type of circuit that includes discrete gate and/or transistor logic. The processor 104 may be a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, any processor described herein may include multiple processors, parallel processors, or both. Multiple processors may be included in, or coupled to, a single device or multiple devices.”). The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. Therefore, it is reasonable to infer from applicant’s specification that the above additional elements are purely generic. Thus, these additional limitations, considered individually and in combination, amount to mere instructions to implement an abstract idea on a general-purpose computer or use the computer as a tool to perform an abstract idea and therefore do not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Independent claim 10 is directed to the computing apparatus reciting similar limitations and does not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims, individually or in combination, do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Similarly, independent claim 19 is directed to the non-transitory computer readable storage medium reciting similar limitations and does not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims, individually or in combination, do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Dependent claims 2-5, 7-9, 11-14, 16-18, and 20 only narrow the abstract idea and do not add significantly more (i.e. an inventive concept) to the abstract idea. The claims are ineligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 7-14, and 16-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by the patent publication Makhdumi et al. (Publication No.: US 2015/0248664 A1).
As to Claim 1, Makhdumi teaches a method for facilitating a cashless payment, the method being implemented by at least one processor, the method comprising:
receiving, by the at least one processor, an identification number that corresponds to a request for payment submitted by a potential payee, the identification number excluding personally identifying information a database, e.g., merchant database 404. For example, the merchant server may utilize PHP/SQL commands similar to the examples provided above to query a relational database. In response to the batch data request, the database may provide the requested batch data, e.g., 440. The server may generate a batch clearance request, e.g., 441, using the batch data obtained from the database, and provide, e.g., 442, the batch clearance request to an acquirer server, e.g., 410. For example, the merchant server may provide a HTTP(S) POST message including XML-formatted batch data in the message body for the acquirer server. The acquirer server may generate, e.g., 443, a batch payment request using the obtained batch clearance request, and provide the batch payment request to the pay network server, e.g., 444. The pay network server may parse the batch payment request, and extract the transaction data for each transaction stored in the batch payment request, e.g., 445. The pay network server may store the transaction data, e.g., 446, for each transaction in a database, e.g., pay network database 407. For each extracted transaction, the pay network server may query, e.g., 447-448, a database, e.g., pay network database 407, for an address of an issuer server. For example, the pay network server may utilize PHP/SQL commands similar to the examples provided above. The pay network server may generate an individual payment request, e.g., 449, for each transaction for which it has extracted transaction data, and provide the individual payment request, e.g., 450, to the issuer server, e.g., 408.”, and ¶[0089] – “the merchant server may initiate clearance of a batch of authorized transactions. For example, the merchant server may generate a batch data request, e.g., 535, and provide the request, e.g., 536, to a database, e.g., merchant database. In response to the batch data request, the database may provide the requested batch data, e.g., 536. The server may generate a batch clearance request, e.g., 537, using the batch data obtained from the database, and provide the batch clearance request to an acquirer server. The acquirer server may generate, e.g., 539, a batch payment request using the obtained batch clearance request, and provide the batch payment request to the pay network server. The pay network server may parse the batch payment request, and extract the transaction data for each transaction stored in the batch payment request, e.g., 540-542. The pay network server may store the transaction data, e.g., 543-544, for each transaction in a database, e.g., pay network database. For each extracted transaction, the pay network server may query, e.g., 545-546, a database, e.g., pay network database, for an address of an issuer server. The pay network server may generate an individual payment request, e.g., 547, for each transaction for which it has extracted transaction data, and provide the individual payment request to the associated issuer server.”);
automatically retrieving, by the at least one processor based on the received identification number
transmitting, by the at least one processor to the potential payor, a first message that includes a request for confirmation that the potential payor intends to make a payment to the potential payee and a request for an amount of the payment (see ¶[0041] – “For example, in some implementations, a user shopping online via a web browser executing on a client device, e.g., 190, may desire to pay for a purchase of items from an online shopping website, e.g., 191. The website may include a user interface element that the user may activate to initiate shopping checkout and payment. Upon the user activating the user element, the client displaying the online shopping website may provide a message to a server of the merchant to initiate secure purchase transaction processing. The server of the merchant operating the online shopping website may establish a secure connection (e.g., a Secure Sockets Layer connection) to a pay network server of a payment network, e.g., 192. Also, the pay network server may establish a secure connection to the client. For example, the client may include a secure I/O chip that only allows secure connections to be established by the client with pay network servers of the payment network. Via the secure connection, the pay network server may provide an instruction to the client to request the user to launch a virtual wallet mobile app on the user device of the user, see e.g., FIG. 1F, 196. The client may accordingly provide a request to the user to launch a virtual wallet mobile app on the user device, e.g., 193, of the user. Upon the user launching the virtual wallet mobile app on the user device, the user device and the client may establish a secure connection with each other (e.g., via Bluetooth.TM., Wi-Fi, cellular, etc.) In some implementations, the client and user device may be preconfigured to rapidly establish the secure communication channel with each other. Via the secure communication channel, the client may provide data to the user's mobile device, or vice versa, to facilitate initiation of the purchase transaction. The virtual wallet app on the user's mobile device (or the client) may then generate a purchase transaction initiation message and provide it to the pay network server for processing the purchase transaction. Upon completion of transaction processing, the pay network server may provide a notification of payment completion to the client, e.g., FIG. 1F, 197, or to the user device.”);
receiving, by the at least one processor from the potential payor, a second message that includes the requested confirmation and the requested amount of the payment (see ¶[0041]);
validating, by the at least one processor based on the received second message, the request for payment (see ¶[0041]);
transferring, to the potential payee, a cookie that is associated with the requested amount of the payment (see ¶[0061] – “In some implementations, pre-designed QR codes associated with authenticated with pre-authenticated merchants may be provided to the user device. For example, a user may be browsing an online website on the user's device. The user device may make a HTTP(S) GET request for a webpage from a web server. In some implementations, the web server may, in response to the user device's request for a webpage, generate a query for advertisements to display on the webpage. For example, the web server may search a database, or provide a request to an ad network server (e.g., Akamai) to provide advertisements for embedding into the webpage. In some implementations, the ad network server may utilize keywords, metadata, etc. obtained from the web server (e.g., keywords or metadata associated with the webpage, user profile information, user ID, user browsing history from a cookie stored on the user device, etc.). The ad network may utilize the keywords to generate a query of database(s) for advertisements associated with the keywords, and may obtain advertisements to provide.”); and
when a confirmation that the requested payment has been completed is received, transmitting, by the at least one processor to the payor, a confirmation that the requested payment has been completed, wherein the identification number that corresponds to the request for payment is received from an entity associated with a Uniform Resource Locator (URL) address accessed by the potential payee in order to submit the request for payment (see ¶[0035] – “In some implementations, a user alert mechanism may be built into the snap mobile payment purchase transaction process flow. For example, in some implementations, a merchant server may embed a URL specific to the transaction into the card authorization request. For example, in some implementations, a POS terminal, remote device and/or desktop computer may embed the URL into optional level 3 data in the card authorization request. The URL may point to a webpage stored on the merchant's server dedicated to the transaction that is the subject of the card authorization request. For example, the webpage pointed to by the URL may include details on the purchase transaction, e.g., products being purchased, purchase cost, time expiry, status of order processing, and/or the like. Thus, the merchant server may provide to the payment network the details of the transaction by passing the URL of the webpage to the payment network. In some implementations, the payment network may provide notifications to the user, such as a payment receipt, transaction authorization confirmation message, shipping notification and/or the like. In such messages, the payment network may provide the URL to the user device. The user may navigate to the URL on the user's device to obtain alerts regarding the user's purchase, as well as other information such as offers, coupons, related products, rewards notifications, and/or the like.”).
As to Claim 2, Makhdumi teaches the method of claim 1, further comprising determining, by the at least one processor, that a device associated with the potential payor is within a predetermined distance of a device associated with the potential payee (see ¶[0191] – “In some embodiments, the geolocation module 1514 may be able to determine if the consumer and mobile device 1510 are within or near a merchant 1520 location. For example, the geolocation module 1514 may store information about one or more merchant 1520 locations, such as one or more sets of coordinates or addresses associated with one or more merchant 1520 locations. The geolocation module 1514 may determine the position of the mobile device 1510, and then compare the position of the mobile device 1510 with the information about one or more merchant 1520 locations. If the mobile device 1510 has the same position as a merchant 1520 location, or if it is within a predetermined distance of a merchant 1520 location (e.g. within 10, 20, 50, or 100 feet), then the geolocation module 1514 may determine that the consumer and mobile device are within or near the merchant 1520 location. For example, the consumer may be shopping at a certain merchant 1520. In some embodiments, the geolocation module 1514 may be in communication with a GPS system (or another location system), and the GPS system may inform the geolocation module 1514 when the mobile device 1510 is at or near a certain merchant 1520 location.”)
As to Claim 3, Makhdumi teaches the method of claim 1, wherein the validating comprises determining whether the account associated with the potential payor has sufficient funds for executing the requested payment (see ¶[0074] – “In some implementations, on obtaining the user data, e.g., 427a-n, the issuer server may determine whether the user can pay for the transaction using funds available in the account, e.g., 428a-n. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. Based on the determination, the issuer server(s) may provide an authorization response, e.g., 429a-n, to the pay network server. For example, the issuer server(s) may provide a HTTP(S) POST message similar to the examples above. In some implementations, if at least one issuer server determines that the user cannot pay for the transaction using the funds available in the account, see e.g., 430-431, the pay network server may request payment options again from the user (e.g., by providing an authorization fail message 431 to the user device and requesting the user device to provide new payment options), and re-attempt authorization for the purchase transaction.”).
As to Claim 4, Makhdumi teaches the method of claim 3, wherein the validating further comprises determining whether the request for payment violates a rule relating to fraud prevention (see ¶[0133] – “With reference to FIG. 13B, in some implementations, the app executing on the user's device may provide a "VerifyChat" feature for fraud prevention. For example, the SNAP may detect an unusual and/or suspicious transaction. The SNAP may utilize the VerifyChat feature to communicate with the user, and verify the authenticity of the originator of the purchase transaction.”).
As to Claim 5, Makhdumi teaches the method of claim 3, wherein the validating further comprises determining whether the request for payment is anomalous with respect to a pattern that has previously been observed with respect to the potential payor (see ¶[0133]).
As to Claim 7, Makhdumi teaches the method of claim 1, further comprising:
when a request for validation of an amount to be dispersed to the potential payee is received from a merchant, transmitting, to the merchant, a validation of the amount;
deducting, from the account associated with the payor, the amount; marking the account with an indication that the requested payment has been completed; and
coordinating with the merchant to ensure that the merchant receives compensation for the amount paid to the payee (see ¶[0090] – “In some implementations, the issuer server may generate a payment command, e.g., 548-549. For example, the issuer server may issue a command to deduct funds from the user's account (or add a charge to the user's credit card account). The issuer server may issue a payment command, e.g., 549, to a database storing the user's account information, e.g., user profile database. The issuer server may provide a funds transfer message, e.g., 551, to the pay network server, which may forward the funds transfer message to the acquirer server. In some implementations, the acquirer server may parse the funds transfer message, and correlate the transaction (e.g., using the request ID field in the example above) to the merchant. The acquirer server may then transfer the funds specified in the funds transfer message to an account of the merchant, e.g., 553-555.”).
As to Claim 8, Makhdumi teaches the method of claim 1, further comprising transmitting, to the payee in conjunction with the transferring of the cookie, information that relates to at least one option for obtaining the requested payment which is displayable on a smart phone (see ¶[0028] – “The user may capture an image of the QR code generated by the POS terminal using a user device, such as a smartphone.”, and ¶[0061] – “In some implementations, pre-designed QR codes associated with authenticated with pre-authenticated merchants may be provided to the user device. For example, a user may be browsing an online website on the user's device. The user device may make a HTTP(S) GET request for a webpage from a web server. In some implementations, the web server may, in response to the user device's request for a webpage, generate a query for advertisements to display on the webpage. For example, the web server may search a database, or provide a request to an ad network server (e.g., Akamai) to provide advertisements for embedding into the webpage. In some implementations, the ad network server may utilize keywords, metadata, etc. obtained from the web server (e.g., keywords or metadata associated with the webpage, user profile information, user ID, user browsing history from a cookie stored on the user device, etc.).”).
As to Claim 9, Makhdumi teaches the method of claim 8, wherein the information that relates to the at least one option for obtaining the requested payment includes at least one from among a tap at a first automatic teller machine (ATM) associated with a bank that administers the account associated with the potential payor; entering a code into the first ATM; scanning one from among a Quick Response (QR) code and a barcode at one from among a branch of the bank and a merchant location; information that is usable for obtaining the requested payment via an account that is hosted in a metaverse; and information that is usable by a money transfer application in order to have the payment delivered directly to a bank account associated with the potential payee (the bold portion is considered intended use and is not given patentable weight) (see ¶[0028], and ¶[0053] – “FIGS. 4A-D show data flow diagrams illustrating an example snap mobile payment procedure in some embodiments of the SNAP. With reference to FIG. 4A, in some implementations, a user, e.g., 401, may desire to purchase a product, service, offering, and/or the like ("product"), from a merchant, e.g., 403, via a merchant online site or in the merchant's store. The user may communicate with a merchant server, e.g., 403, via a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 402).”.
Claim 10 is the computing apparatus comprising: a processor; a memory; and a communication interface coupled to each of the processor and the memory, wherein the processor is configured to perform the method of Claim 1 and is rejected under the same reasoning as Claim 1.
Claim 11 is the computing apparatus for performing the method of Claim 2 and is rejected under the same reasoning as Claim 2.
Claim 12 is the computing apparatus for performing the method of Claim 3 and is rejected under the same reasoning as Claim 3.
Claim 13 is the computing apparatus for performing the method of Claim 4 and is rejected under the same reasoning as Claim 4.
Claim 14 is the computing apparatus for performing the method of Claim 5 and is rejected under the same reasoning as Claim 5.
Claim 16 is the computing apparatus for performing the method of Claim 7 and is rejected under the same reasoning as Claim 7.
Claim 17 is the computing apparatus for performing the method of Claim 8 and is rejected under the same reasoning as Claim 8.
Claim 18 is the computing apparatus for performing the method of Claim 9 and is rejected under the same reasoning as Claim 9.
Claim 19 is the non-transitory computer readable storage medium comprising executable code which, when executed by at least one processor, causes the at least one processor to perform the method of Claim 1 and is rejected under the same reasoning as Claim 1.
Claim 20 is the non-transitory computer readable storage medium comprising executable code which, when executed by at least one processor, causes the at least one processor to perform the method of Claim 2 and is rejected under the same reasoning as Claim 2.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE S KANG whose telephone number is (571)270-3611. The examiner can normally be reached on Monday through Friday between M-F 10am-2pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matt Gart may be reached at (571)-273-3955. 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.
/IRENE KANG/
Examiner, Art Unit 3695
2/7/2026
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696