DETAILED ACTION
Status of Claims
Claim 1, 5, and 15 have been amended.
Claim 7 has been cancelled.
Claims 1-6 and 8-31 are currently pending and have been considered by the examiner.
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 .
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 9 July 2025 has been entered.
Response to Arguments
101 Rejection:
Applicant asserts that the newly amended claims are patent eligible under 35 USC 101. The examiner respectfully disagrees based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant’s arguments have been considered and are moot in view of new grounds for rejection.
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-6 and 8-31 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-29 are directed to a method, claim 30 is directed to an system/apparatus, and claim 31 is directed to a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method for redeeming a digital asset for a physical asset, the method comprising:
receiving a request to redeem a physical asset corresponding to a digital asset, wherein the redemption request comprises an indication of a cryptographic token on a distributed ledger corresponding to the digital asset;
validating the redemption request; and
updating the cryptographic token on the distributed ledger to include information regarding the physical asset.
generating the digital asset, wherein the digital asset comprises one or more digital files and each of the one or more digital files includes a digital representation of the digital asset;
storing a digital file of the one or more digital files on a decentralized file storage system;and
obtaining a first cryptographic hash representing the stored digital file.
Regarding Step 2A Prong One, the claims recite the abstract idea of the fundamental economic practice of performing an economic transaction. Specifically, the claims recite the limitations underlined above which recite the process of performing an economic transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of performing an economic transaction. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “distributed ledger” and “digital file” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “distributed ledger” and “digital file” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “distributed ledger” and “digital file” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “distributed ledger” and “digital file” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite performing an economic transaction. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-6, 7-14 and 16-29 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claim 2, 5 merely recite additional method steps which are required to perform the recited abstract idea.
Claims 3-4, 6, 8-9, 14-15, 21 merely recite additional method steps which are directed towards the recited abstract idea.
Claim 10-12, 16-20, 22-29 merely further describe elements used to the perform the recited abstract idea.
Claim 13 merely further describes method steps directed towards the abstract idea.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 8-14, and 16-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Verona (WO 2020092900 A2) in view of Boneh et al. (US 20200389312 A1).
Regarding Claims 1 and 30-31, Verona discloses:
A method for redeeming a digital asset for a physical asset (See Verona: Para. [0012-0013] – “In some embodiments, the set of tokens corresponding to a virtual representation are transferrable to other users. In some embodiments, the item is one of a digital good, a physical good, a digital service, a physical service, a digital experience, or a digital experience … The method also includes receiving, by the digital wallet graphical user interface, an instruction to transfer a token from the inventory of tokens to a recipient”), the method comprising:
receiving a request to redeem a physical asset corresponding to a digital asset, wherein the redemption request comprises an indication of a cryptographic token on a distributed ledger corresponding to the digital asset (See Verona: Para. [0011-0012] and [0218] – “According to some embodiments of the present disclosure, a method for facilitating transactions via a tokenization platform is disclosed” and “According to some embodiments of the present disclosure, a method for facilitating transactions via a tokenization platform includes maintaining a ledger, providing a digital marketplace”);
validating the redemption request (See Verona: Para. [0011] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distribuled ledger.”); and
updating the cryptographic token on the distributed ledger to include information regarding the physical asset (See Verona: Para. [0011] and [0686] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distributed ledger.” and “receiving, by a processing system, a request to securitize an asset of a user, receiving, by the processing system, one or more photographs of the asset, receiving, by the processing system, item information relating to the asset, receiving, by the processing system, a holding location of the asset, generating, by the processing system, a virtual representation of the asset based on the one or more photographs, the item information, and the hold location”).
generating the digital asset, wherein the digital asset comprises one or more digital files and each of the one or more digital files includes a digital representation of the digital asset (See Verona: Para. [0830] – “As used herein, unless otherwise indicated by context, “cryptographically” indicates use of a cryptographic algorithm, such as a hashing algorithm.” And Para. [0972] – “the selectable media content includes the digital token/an identifier of the digital token (e.g., a hash value that uniquely identifies the digital token)” – The examiner asserts that Verona discloses that the generated selectable media content includes a digital token which functions as a digital representation of said asset);
storing a digital file of the one or more digital files on a decentralized file storage system ;and
obtaining a first cryptographic hash representing the stored digital file (See Verona: Para. [0830] – “As used herein, unless otherwise indicated by context, “cryptographically” indicates use of a cryptographic algorithm, such as a hashing algorithm.” And Para. [0972] – “the selectable media content includes the digital token/an identifier of the digital token (e.g., a hash value that uniquely identifies the digital token)” – The examiner asserts that Verona discloses that the “obtained” selectable media content includes a hash value, which is a cryptographic hash, which represents the asset. As both the hash and the digital token/file are representative of the same asset, the transitive property applies and thus the hash must in some form correspond to/represent the digital token/file).
Verona fails to explicitly disclose:
storing a digital file of the one or more digital files on a decentralized file storage system
However, in a similar field of endeavor, Boneh discloses:
storing a digital file of the one or more digital files on a decentralized file storage system (See Boneh: Para. [0003] – “Other example contexts for decentralized computing platforms include storage or processing of digital assets, like digital files and other data, and incentives for storage or processing of those assets may be real or digital currency or some other asset (e.g., compute time in exchange for storage or vice versa)”)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date to substitute the generic data storage system of Verona for the decentralized file storage system of Boneh, yielding the predictable result of an increase in security of the invention by increasing the tamper-resistance of the system.
Regarding Claim 2, Verona discloses:
further comprising: manufacturing the physical asset (See Verona: Para. [0878] – “In embodiments, the buyer marketplace system 204 may allow users to purchase made-to-order items. For example, a user may order a customized pizza, piece of furniture, flower arrangement, or the like. Users can digitally build items consisting of multiple items from multiple merchants and have it 3D printed at a 3D printing station.”).
Regarding Claim 3, Verona discloses:
further comprising: transmitting a first message comprising a prompt, wherein the prompt includes one or more parameters to customize the physical asset (See Verona: Para. [0878] – “In embodiments, the buyer marketplace system 204 may allow users to purchase made-to-order items. For example, a user may order a customized pizza, piece of furniture, flower arrangement, or the like. Users can digitally build items consisting of multiple items from multiple merchants and have it 3D printed at a 3D printing station.”);
transmitting the first message towards a user device; and receiving a second message comprising one or more values for the one or more parameters for manufacturing the physical asset according to the one or more values for the one or more parameters (See Verona: Para. [0848] – “In some embodiments, the transmitted token may be embedded m a media content, such as an image, emoji, or video, such that the recipient receives the media content and may opt to accept the token. In this example, the token may be accompanied by a link and/or software instructions that cause the user device 190 that receives the token to add the token to the recipient’s account upon the recipient accepting the token. Upon electing to accept the token, the user device 190 of the recipient may transmit a request to the platform to add the token to an account of the recipient”).
Regarding Claim 4, Verona discloses:
wherein the information comprises an indication that the physical asset has been redeemed (See Verona: para. [0854] – “In embodiments, the platform 100 provides a marketplace system 102 that allows virtual representations of items to be defined, generated, viewed, and/or redeemed. In embodiments, the marketplace system 102 may include graphical user interfaces that: allow sellers to define virtual representations, allow consumers to view virtual representations of items and to transact for tokens corresponding to the items, and allow token owners to redeem tokens, thereby completing transactions for items indicated by the redeemed tokens”).
Regarding Claim 5, Verona discloses:
further comprising: generating the digital asset, wherein the digital asset comprises one or more digital files and each of the one or more digital files includes a digital representation of the digital asset; and recording information related to the digital asset as the cryptographic token on the distributed ledger, said information including at least a first cryptographic hash representing the digital asset and ownership information associated with the digital asset (See Verona: Para. [0011] and [0686] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distributed ledger.” and “receiving, by a processing system, a request to securitize an asset of a user, receiving, by the processing system, one or more photographs of the asset, receiving, by the processing system, item information relating to the asset, receiving, by the processing system, a holding location of the asset, generating, by the processing system, a virtual representation of the asset based on the one or more photographs, the item information, and the hold location”).
Regarding Claim 6, Verona discloses:
receiving a request to purchase the digital asset, wherein the purchase request comprises transaction information identifying at least the cryptographic token and a digital wallet associated with a user;
transmitting, upon validation of the purchase request, cryptographic information to the digital wallet associated with the user, wherein the cryptographic information links the user with the cryptographic token; updating the digital ledger to record the transaction (See Verona: Para. [0011] and [0686] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distributed ledger.” and “receiving, by a processing system, a request to securitize an asset of a user, receiving, by the processing system, one or more photographs of the asset, receiving, by the processing system, item information relating to the asset, receiving, by the processing system, a holding location of the asset, generating, by the processing system, a virtual representation of the asset based on the one or more photographs, the item information, and the hold location”); and
updating the cryptographic token with information related to the transaction, said information including at least new ownership information based on the transaction (See Verona: Para. [0011] and [0686] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distributed ledger.” and “receiving, by a processing system, a request to securitize an asset of a user, receiving, by the processing system, one or more photographs of the asset, receiving, by the processing system, item information relating to the asset, receiving, by the processing system, a holding location of the asset, generating, by the processing system, a virtual representation of the asset based on the one or more photographs, the item information, and the hold location”).
Regarding Claim 8, Verona discloses:
wherein the cryptographic token further includes information referencing the second cryptographic hash (See Verona: Para. [0830] – “As used herein, unless otherwise indicated by context, “cryptographically” indicates use of a cryptographic algorithm, such as a hashing algorithm.” And Para. [0972] – “the selectable media content includes the digital token/an identifier of the digital token (e.g., a hash value that uniquely identifies the digital token)”).
Regarding Claim 9, Verona discloses:
further comprising: uploading the one or more digital files to a remote server (See Verona: Para. [9943] – “Once an expert wins a bid, the expert performs the authentication and/or appraisal based on the information uploaded by the user (e.g., one or more high resolution photographs of the virtual item, a 3D representation of the item, dimensions of the item, a weight of the item, and/or the like). The expert may provide an appraisal value and/or a determination indicating the authenticity of the item”).
Regarding Claim 10, Verona discloses:
wherein the cryptographic token further includes metadata identifying a location of the one or more digital files (See Verona: Para. [0838] – “In some embodiments, the platform may“tokenize” an item on behalf of a seller of the item by generating a set of tokens based on the virtual representation of the item and storing the tokens and associated metadata in a cryptographically secure distributed ledger, thereby making the tokens (and the virtual representation) verifiable, transferable, and trackab!e.”)
Regarding Claim 11, Verona discloses:
wherein the digital wallet is provided by a third-party service (See Verona: Para. [0159] – “In embodiments, the digital wallet-less system is integrated with a messaging system.”).
Regarding Claim 12, Verona discloses:
wherein the digital wallet is created by the user (See Verona: para. [0013] – “The method further includes transmitting, by the digital wallet, the text-based message having the token embedded therein to a message account of the recipient, wherein the recipient can select the selectable media content to accept to the token into a respecti ve digital wallet of the recipient.”).
Regarding Claim 13, Verona discloses:
wherein the validation of the purchase request comprises: determining the user associated with the purchase request; and determining that the user placed a winning bid for the digital asset at an auction (See Verona: para. [0532] – “In embodiments, the set of workflows includes a workflow configured to bid for the unique digital token.”).
Regarding Claim 14, Verona discloses:
further comprising: updating the cryptographic token to include information relating to one or more of a price of the digital asset or a price of the physical asset (See Verona: Para. [0011] and [0686] – “The method further includes receiving a transfer request to transfer the specific token to a different user, wherein the transfer request includes a token identifier that identifies the specific token and a public address of the different user and validating the specific token based on the token identifier and the distributed ledger.” and “receiving, by a processing system, a request to securitize an asset of a user, receiving, by the processing system, one or more photographs of the asset, receiving, by the processing system, item information relating to the asset, receiving, by the processing system, a holding location of the asset, generating, by the processing system, a virtual representation of the asset based on the one or more photographs, the item information, and the hold location”).
Regarding Claim 16, Verona discloses:
wherein the digital asset is one of a limited amount of identical digital assets (See Verona: Para. [0049] – “In embodiments, the set of origination attributes includes limited-edition attributes, celebrity-signature attributes, certification of originality attributes, location of origin attributes, certification of ethical production attributes, or creator attributes.”).
Regarding Claim 17, Verona discloses:
wherein the digital asset is unique (See Verona: Para. [0056] – “In embodiments, the real-world object is a unique instance of a digital item”).
Regarding Claim 18, Verona discloses:
wherein the physical asset is one of many identical physical assets (See Verona: Para. [0055] – “In embodiments, the real-world object is a consumer product”).
Regarding Claim 19, Verona discloses:
wherein the physical asset is one of a limited amount of identical physical assets (See Verona: Para. [0059] – “In embodiments, the real-world object has a defined type and a defined set of characteristics but is not yet in existence”).
Regarding Claim 20, Verona discloses:
wherein the physical asset is a unique physical asset (See Verona: Para. [0059] – “In embodiments, the real-world object has a defined type and a defined set of characteristics but is not yet in existence”).
Regarding Claim 21, Verona discloses:
further comprising: creating a unique domain name associated with the digital asset, wherein the unique domain name is recorded on the distributed ledger as a second cryptographic token, and wherein there is an association between the first cryptographic token and the second cryptographic token (See Verona: Para. [0994] – “The methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and/or netw'orking hardware. The software program may be associated with a server that may incl ude a file server, print server, domain server, Internet server, intranet server, cloud server, and other variants such as secondary server, host server, distributed server and the like.”)
Regarding Claim 22, Verona discloses:
wherein the unique domain name resolves to a webpage that includes information about the digital asset (See Verona: Para. [0840] – “The content may include links to the item (e.g., a link to a webpage or application state corresponding to the item).”).
Regarding Claim 23, Verona discloses:
wherein the physical asset is one or more of: footwear, apparel, equipment, an event ticket, and a functional asset (See Verona: Para. [0057] – “In embodiments, the real-world object is a gift card.”).
Regarding Claim 24, Verona discloses:
wherein the distributed ledger is a blockchain ledger (See Verona: para. [0155] – “In embodiments, the linking system uses a blockchain”).
Regarding Claim 25, Verona discloses:
wherein the digital wallet is a blockchain-based wallet (See Verona; Para. [0153] – “In embodiments, the digital wallet-less system enables the exchange of the cryptocurrency upon parsing of a coded message”).
Regarding Claim 26, Verona discloses:
wherein the cryptographic token is a non-fungible token (NFT) (See Verona: para. [0907] – “In some embodiments, the N tokens include non -fungible tokens. In embodiments, the N tokens include fungible tokens.”).
Regarding Claim 27, Verona discloses:
wherein the cryptographic token is one or more of: an Ethereum Request for Comments (ERC) standard token or a Solana (SOL) token (See Verona: para. [0844] – “In embodiments, the distributed ledger is a blockchain (e.g , an Ethereum blockchain)”).
Regarding Claim 28, Verona discloses:
wherein the cryptographic token is a governance token that includes the ability to vote on and/or to participate in certain actions (See Verona: Para. [0686] – “receiving, by the processing system, an agreement to provide a service for the user by a provider using the asset as collateral, generating, by the processing system, an instance of a smart contract governing the service”).
Regarding Claim 29, Verona discloses:
wherein the one or more digital files includes two- dimensional design files and/or three-dimensional design files (See Verona: Para. [0829] – “As used herein the term“item” may refer to a digital asset (e.g., gift card, digital music file, digital video file, software, digital photograph, etc.)”).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Verona in view of Boneh in further view of Iida et al. (US 20030047602 A1).
Regarding Claim 15, Verona discloses:
determining, using the pricing information, royalty payments reflecting predetermined ratios (See Verona: Para. [0872] – “The GUI may then allow a user to define the item attributes in item attribute fields. Item attribute fields may include, but are not limited to, an item name, an item description, item notes, an item image, item pricing data (e.g., suggested price, suggested floor price), an instant sell flag, an item URL that links to a webpage for purchasing the item, a quantity of items, and the like. When a user provides the requisite item attributes, the item management system 202 may create a new virtual representation defining the new item.”).
method for redeeming a digital asset for a physical asset, the method comprising: receiving a request to redeem a physical asset corresponding to a digital asset, wherein the redemption request comprises an indication of a cryptographic token on a distributed ledger corresponding to the digital asset; validating the redemption request; updating the cryptographic token on the distributed ledger to include information regarding the physical asset; generating the digital asset, wherein the digital asset comprises one or more digital files and each of the one or more digital files includes a digital representation of the digital asset; storing a digital file of the one or more digital files on a decentralized file storage system; and obtaining a first cryptographic hash representing the stored digital file (The aforementioned claim limitations recite subject matter similar to that recited in independent claim 1 and thus are disclosed by Verona as outlined in the rejection of claim 1 of this action); updating the cryptographic token to include information relating to one or more of a price of the digital asset or a price of the physical asset (See Verona: Para. [0872] – “The GUI may then allow a user to define the item attributes in item attribute fields. Item attribute fields may include, but are not limited to, an item name, an item description, item notes, an item image, item pricing data (e.g., suggested price, suggested floor price), an instant sell flag, an item URL that links to a webpage for purchasing the item, a quantity of items, and the like. When a user provides the requisite item attributes, the item management system 202 may create a new virtual representation defining the new item.”); and
However, Verona fails to explicitly disclose:
determining, using the pricing information, royalty payments reflecting predetermined ratios.
However, in a similar field of endeavor, Iida discloses a royalty determination unit capable of determining royal payments based upon predetermined ratios (See Iida: Para. [0642] – “The host computer 5302 includes the accounting and royalty determining unit 5319 provided with a function for determining the royalty distribution ratios based on the relations of right of the applicable copyright determined by the applicable copyright related information determining unit 5318, and the information stored in the accounting approval database 5311”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system of Verona and Boneh to incorporate the functionality of the royalty determining unit disclosed by Iida to determine royalty payments yielding the predicable result of a more efficient invention through the use of modular system design.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Andon et al. (US 20230327866 A1) generally discloses a method of provisioning or distributing a cryptographic digital asset.
Mulas et al. (US 20230031817 A1) generally discloses a system and a method for authenticating and certifying a physical item are provided.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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 on 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 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699 /NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699