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 Amendment(s)
This is response to the amendments filed on 7/25/2025. Claims 1-4, 7, 10-13, 19, and 20 have been amended. Claims 1-20 are currently pending, and have been considered below, as no claims have been canceled.
Response to Arguments
Applicant's arguments filed 7/25/2025 have been fully considered but they are not persuasive.
On page 11 of the remarks, with regard to the Zappier (US 2018/0204213) reference, Applicant states: “the Zappier reference appears to be silent regarding requiring a different number/type of authentication credentials based on the transaction block type (e.g., read, write, etc.).” This argument is not persuasive.
The claims do not require “different number/type of authentication”. Rather the claims permit the interpretation that all blocks regardless of number or type require the same authentication credentials.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “different number/type of authentication”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
It is noted that Zappier does contemplate different authentication credential requirements based on access type:
(Zappier, ¶0072, “the system determines, based on validating the authentication credentials of the first user, that the first user is authorized to access at least one decentralized application. Typically, the number of decentralized applications to which the user has access depends on the status of the user.” The credentials required are different based on the application type.)
The Suzuki (US 2020/0162240) and Yang (US 10,417,219) references were not relied upon for type of transaction block.
In summary, Applicant’s arguments are not persuasive as they assert unclaimed subject matter and separately are not persuasive as the Zappier reference does disclose the argued scope.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Suzuki” (US 20200162240) in view of “Zappier et al.” (US 20180204213) further in view of “Yang et al.” (US 10417219).
Regarding claim 1:
Suzuki teaches:
A system (¶0030, “communication system 100 provides a data trade service by using the blockchain”) comprising:
one or more microprocessors (¶0084, “This computer 300 includes a processor 301”); and
a computer readable medium, coupled with the one or more microprocessors (¶0084, “This computer 300 includes a processor 301, a memory 302, a storage device 303”) and comprising:
microprocessor readable and executable instructions that, when executed by the one or more microprocessors (¶0085, “the processor 301 can carry out the data registration procedures and the data acquiring procedures by executing communication programs stored in the storage device 303”), cause the one or more microprocessors to:
receive (Fig 15, S11, “receive data acquiring request transaction”), by a plurality of nodes that are part of a distributed blockchain ledger (¶0010, “a communication device provides data to a data acquiring node based on a consensus of a plurality of participating nodes” i.e., examiner interprets consensus necessitates distributed blockchain ledger), a request to add a first transaction block …of blockchains in the distributed blockchain ledger (¶0043, “participating nodes on the network generate transactions one after another. Miners verify blocks including plural transactions and transmit the verification results to all nodes. As a result, blocks are added to a blockchain in each of the nodes”), wherein the first transaction block comprises one or more transaction block authentication credentials (¶0038, “Miner #1 verifies block B that includes transactions Tx1, Tx2, and Tx3. These verification results are transmitted to all participating nodes” i.e., examiner interprets each of the participating nodes has a function to perform cryptographic communication which generates a pair of public key and secret key which necessitates credentials as described in para 33);
…
determine, by each of the plurality of nodes (e.g. a consensus, ¶ 0005 “The consensus algorithms allow a process to be confirmed after plural participating nodes verify processing details and processing results.”) that are part of the distributed blockchain ledger (¶0040, “in PoW, when six blocks are connected after a target block, the target block is determined to be confirmed. Then the participating nodes can execute transactions in the confirmed block” i.e., examiner interprets nodes are connected to the blockchain which necessitates part of the distributed blockchain ledger as described in para 37), if the one or more transaction block authentication credentials received are valid (¶0042, “A miner verifies block 1 that includes a data acquiring request transaction and transmits the verification result to all nodes” further elaborated in ¶0043, “Miners verify blocks including plural transactions and transmit the verification results to all nodes. As a result, blocks are added to a blockchain in each of the nodes” i.e., examiner interprets blocks are added to blockchain necessitates validation after the verification by miners);
receive an indication from at least a majority of the plurality of nodes that are part of the distributed blockchain ledger that the one or more transaction block authentication credentials are valid (¶0054, “The data provider 11 generates an address list relating to registration of data D. This address list includes access right information, a list of decrypting nodes, and encrypted addresses… The access right information indicates participating nodes that are allowed to access data D” i.e., examiner interprets participating nodes generates a data acquiring request transaction to request data D which can necessitates transaction block as described in para 35); and
in response to receiving the indication from the at least the majority of the plurality of nodes that are part of the distributed blockchain ledger (¶0055, “on the blockchain as a result of execution of data registration contrast. Each of the participating nodes stores the address list received from the data provider 11. With this processing, the data registration procedures are completed”) that the one or more transaction block authentication credentials are valid (¶0056, “the data provider 11 generates encrypted addresses ADD1 to ADD4 by encrypting address ADD1 to ADD4 with public keys PK1 to PK4 of the participating nodes 1 to 4. An address list that includes the encrypted addresses ADD1 to ADD4 is disclosed on the blockchain”), add, by the plurality of nodes that are part of the distributed blockchain ledger (¶0055, “the data provider 11 transmits the address list to all participating nodes … The address list may be recorded”), the first transaction block …of blockchains in the distributed blockchain ledger (¶0058, “This data acquiring request transaction includes a message that requests acquisition of data D. The data acquiring request transaction is transmitted to all participating nodes” i.e., examiner interprets nodes are connected to the blockchain which necessitates in the distributed blockchain ledger).
Suzuki does not explicitly disclose:
…
…a request to add a first transaction block to a plurality of blockchains in the distributed blockchain ledger…;
identify a block type of the first transaction block, wherein the type of the first transaction block is based on a transaction requested;
identify a number and/or type of the one or more transaction block authentication credentials required to add the first transaction block, wherein the number and/or type of the one or more transaction block authentication credentials required is based on the identified type of the first transaction block;
receive, by each of the plurality of nodes that are part of the distributed blockchain ledger, the one or more transaction block authentication credentials;
… the first transaction block to the plurality of blockchains in the distributed blockchain ledger….
Zappier teaches:
…
identify a block type (Zappier, ¶ 6, “determining, based on validating the authentication credentials of the first user, that the first user is authorized to access at least one decentralized application;” the application being the block type) of the first transaction block (Zappier, ¶0006, “a request from a first user to access the blockchain… the data file is associated with a first transaction; detecting, via a consensus algorithm, that the data file is valid; appending the data file to a block in the blockchain…”), wherein the block type of the first transaction block is based on a transaction requested (Zappier, ¶0006, “that the first user is authorized to access at least one decentralized application; receiving, from the user, a request to upload a data file to the blockchain, wherein the data file is associated with a first transaction”);
identify a number and/or type of the one or more transaction block authentication credentials required to add the first transaction block (Zappier, ¶0006, “receiving authentication credentials from the first user; determining, based on validating the authentication credentials of the first user, that the first user is authorized to access at least one decentralized application; receiving, from the user, a request to upload a data file to the blockchain, wherein the data file is associated with a first transaction”);
, wherein the number and/or type of the one or more transaction block authentication credentials required is based on the identified type of the first transaction block; (Zappier, ¶0072, “the system determines, based on validating the authentication credentials of the first user, that the first user is authorized to access at least one decentralized application. Typically, the number of decentralized applications to which the user has access depends on the status of the user.” The credentials required are different based on the application type.);
receive, by each of
the plurality of nodes that are part of the distributed blockchain ledger (Zappier, ¶0040, “Once a pending data record is submitted to the blockchain 241, the nodes 110 may communicate with each other to reach a consensus as to the validity of the pending data record. Said data record may comprise transactional information or documents required to process a resource transfer (e.g. loan documents). Once a consensus has been reached, each node 110 may add the pending data record to the blockchain 241”), the one or more transaction block authentication credentials (Zappier, ¶0040, “The nodes 110 are typically configured to require users and computing systems to be authenticated to access any portion of the blockchain. Accordingly, the nodes 110 may be configured to accept various types of authentication credentials from a user, such as a username and password, secure token, cryptographic key, biometric data…”);
…
Before the effective filing date of the claimed invention, it would have been obvious to one with the ordinary skill in the art to modify Suzuki’s system of transaction block authentication credentials by enhancing Suzuki’s methods of transaction block based on transaction request, transaction block authentication credentials to add transaction block, and nodes that are part of the blockchain ledger with transaction block authentication credentials, as taught by, Zappier, in order to, prevent inefficient resource transfer and provide secure blockchain environment.
The motivation is to enhance the methods of transaction block based on transaction request, transaction block authentication credentials to add transaction block, and nodes that are part of the blockchain ledger with transaction block authentication credentials that may aid in reducing the challenges and securing the transaction (Zappier, ¶0003, “When conducting resource transfers, each entity involved typically uses individual databases to store data needed to conduct the resource transfer. Such traditional methods of conducting resource transfer pose a number of technical challenges. For instance, the data stored on the individual databases may be easily modified or improperly accessed… This may in turn lead to inefficiencies in the resource transfer process that must first be resolved before the resource transfer may be completed. Accordingly, there is a need for a more secure, reliable way to store data relating to resource transfers, while at the same time allowing various disparate systems to access and use such data”).
Suzuki in view of Zappier does not explicitly disclose:
…
…a request to add a first transaction block to a plurality of blockchains in the distributed blockchain ledger…;
…
… the first transaction block to the plurality of blockchains in the distributed blockchain ledger….
Yang teaches:
…
…a request to add a first transaction block to a plurality of blockchains in the distributed blockchain ledger (Col. 9, lines 56-60, “The management server 110 may inquire about details of the requested point transaction (421)…the management server 110 may inquire about a specific block corresponding to a ledger in which details of the transaction have been recorded” i.e., examiner interprets the data sharing system includes a management server 110 and a plurality of blockchains which necessitates plurality of blockchains as shown in fig. 2) …;
…
… the first transaction block to the plurality of blockchains in the distributed blockchain ledger (¶0058, “This data acquiring request transaction includes a message that requests acquisition of data D. The data acquiring request transaction is transmitted to all participating nodes” i.e., examiner interprets nodes are connected to the blockchain which necessitates in the distributed blockchain ledger) ….
Before the effective filling date of the claimed invention, it would have been obvious to one with the ordinary skill in the art to modify Suzuki in view of Zappier’s system of plurality of blockchains in the distributed ledger by enhancing Suzuki in view of Zappier’s method of adding transaction block to plurality of blockchains in the distributed blockchain ledger, as taught by Yang, in order to, securely transmit data sharing in distributed environment.
The motivation is to enhance the method of adding transaction to plurality of blockchains that may aid in securely transferring data across platforms (Yang, Col. 1, lines 53-58, “When blockchain technology is applied to such a sharing economy, all participants may safely register, keep, and share idle resources together, solve security problems such as hacking and manipulation of idle resources, and also ensure the reliability of transaction records through verification”).
Regarding claim 2:
The system of claim 1, wherein Suzuki in view of Zappier further in view of Yang teaches the microprocessor readable and executable instructions further cause the one or more microprocessors to:
generate a first authentication credential (Yang, Col. 5, lines 11-13, “A hash key may be a value used to identify a user in a blockchain network. A hash key may be generated in various ways”), wherein the first authentication credential is a code (Yang, Col. 5, lines 13-16, “Representative hash key generation algorithms are MD5, SHA-256, and the like. A hash key may be a unique value for a specific user. A hash key may be a key composed of a string of a variable length” i.e., examiner interprets string or variable necessitates code); and
provide the first generated authentication credential to each of the plurality of nodes that are part of the distributed blockchain ledger (Suzuki, ¶0033, “Each of the participating nodes 1 to 4 has a function to perform cryptographic communications. In other words, each of the participating nodes 1 to 4 generates a pair of a public key and a secret key” i.e., examiner interprets nodes are connected with blockchain which necessitates part of the distributed blockchain ledger), wherein determining if the one or more transaction block authentication credentials are valid (Suzuki, ¶0043, “Miners verify blocks including plural transactions and transmit the verification results to all nodes. As a result, blocks are added to a blockchain in each of the nodes” i.e., examiner interprets blocks are added to blockchain necessitates validation after the verification by miners) comprises:
comparing, by each of the plurality of nodes that are part of the distributed blockchain ledger (Suzuki, ¶0077, Fig. 15, In S11, “the participating node receives a data acquiring request transaction from a data acquirer” In S12, “the participating node refers to access right information on the address list and determines whether a source node of the data acquiring request transaction has the access right or not”), the first generated authentication credential to a first transaction block authentication credential of the one or more transaction block authentication credentials (Suzuki, ¶0078, Fig. 15, In S13, “the participating node determines whether the participating node itself is designated as a decrypting node on the address list or not” In S14, “when the participating node itself is designated as a decrypting node, the participating node decrypts an encrypted address on the address list with its own private key” In S15, “the participating node transmits an address obtained by the decryption to the source node of the data acquiring request transaction”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 2 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 3:
The system of claim 2, wherein Suzuki in view of Zappier further in view of Yang teaches a plurality of generated authentication credentials are provided to each of the plurality of nodes (Suzuki, ¶0054, “encrypted addresses ADD1 to ADD4 are obtained by encrypting addresses ADD1 to ADD4 with public keys of the participating nodes 1 to 4”), and wherein the plurality of generated authentication credentials (Yang, Col. 5, lines 12-14, “A hash key may be generated in various ways. Representative hash key generation algorithms are MD5, SHA-256”) are based on at least one of:
a plurality of users (Yang, Col. 7, lines 12-15, “the management server 110 may receive and store information on users in a user information blockchain network and perform user authentication on the basis of the stored user information”), a plurality of time periods, a plurality of login sessions, a plurality of authentication factors, and a plurality of single use credentials.
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 3 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 4:
The system of claim 3, wherein Suzuki in view of Zappier further in view of Yang teaches the plurality of generated authentication credentials are based on each of the plurality of users (Yang, Col. 3, lines 6-10, “receiving identification information, such as names, birthdates, and email addresses, of the users as the basic information and registering the basic information in a user information blockchain; performing user authentication through the user information blockchain”), and wherein the plurality of nodes uses a user identifier in the first transaction block to identify the first generated authentication credential from the plurality of generated authentication credentials (Yang, Col. 13, lines 20-29, “The storage server 155 transmits the identified data to the second terminal 20 (762). The second terminal 20 receives the data and decrypts the data with an encryption key (771). Therefore, the second terminal 20 may be required to acquire, in advance, the encryption key for decrypting the data which has been encrypted with a public key…the user information blockchain 120 may have the encryption key for a specific user. The second terminal 20 may acquire, in advance, the encryption key for the specific user through the management server 110”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 4 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 5:
The system of claim 2, wherein Suzuki in view of Zappier further in view of Yang teaches the first generated authentication credential is one of a Short Message Service (SMS) code, an email code, and a chat code (Yang, Col. 3, lines 6-10, “receiving identification information, such as names, birthdates, and email addresses, of the users as the basic information and registering the basic information in a user information blockchain; performing user authentication through the user information blockchain”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 5 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 6:
The system of claim 5, wherein Suzuki in view of Zappier further in view of Yang teaches the first generated authentication credential is a random number that is sent to an external communication device of a user to authenticate the user (Yang, Col. 5, lines11-16, “A hash key may be a value used to identify a user in a blockchain network… A hash key may be a unique value for a specific user. A hash key may be a key composed of a string of a variable length”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 6 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 7:
The system of claim 1, wherein Suzuki in view of Zappier further in view of Yang teaches a first transaction block authentication credential of the one or more transaction block authentication credentials is generated based on a username and wherein a second transaction block authentication credential of the one or more transaction block authentication credentials is one of a Short Message Service (SMS) code, an email code, and a chat code (Yang, Col. 6, lines 31-38, “The user information blockchain 120 stores a hash key for a user and user information… the user information may include the user's identifier, identity (ID), contact information, email address, name, sex, affiliated institution, birthdate, and the like. The user information blockchain 120 may have user information encrypted with a public key” i.e., examiner interprets user information necessitates username because as describes in specification para 25 authentication techniques could be biometrics).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 7 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 8:
The system of claim 1, wherein Suzuki in view of Zappier further in view of Yang teaches the first transaction block has a first block type that requires a different number of transaction block authentication credentials than a second transaction block in the plurality of blockchains in the distributed blockchain ledger (Yang, Col. 6, lines 10-18, Fig. 1, “a node of a blockchain serves as a backend of a general service and a client of a blockchain serves as a client. When a client generates a new transaction, nodes share the transaction through a distributed consensus process and execute the transaction. The client may see results of the transaction… the user terminals 10 and 20 correspond to clients… blockchain nodes correspond to nodes connected to the network”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 8 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 9:
The system of claim 1, wherein Suzuki in view of Zappier further in view of Yang teaches the one or more transaction block authentication credentials comprise a plurality of transaction block authentication credentials (Yang, Col. 9, lines 40-48, “the point transaction information includes transaction counterparty information (user information or a hash key), purchased point information, information on point depositing and withdrawing, remaining point information, transaction amount information, … The user terminal 10/20 may encrypt the point transaction information with a public key and transmit the encrypted information”), and wherein the plurality of transaction block authentication credentials are associated with a plurality of different users (Yang, Col. 9 and 10, lines 65-67 and 1-12, “the point information blockchain 130 may reduce points from a ledger of a specific user (a receiver) and add points to a ledger of another user (a provider)… The management server 110 may verify whether the transaction information received from the point information blockchain 130 and the transaction information received from the user terminal 10/20 coincide with each other (441). When the verification is successful, the management server 110 transmits the changed point transaction information to the user terminal 10/20 (442)”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 9 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 10:
The system of claim 1, wherein Suzuki in view of Zappier further in view of Yang teaches the microprocessor readable and executable instructions further cause the one or more microprocessors to:
provide a first generated authentication credential to each of the plurality of nodes that are part of the distributed blockchain ledger (Yang, Col. 7, lines 34-38, “shows a schematic process for data sharing. Users (a provider and a receiver) perform user registration in advance (210). The management server 110 registers user information and hash keys in a user information blockchain” i.e., examiner interprets each blockchain has plurality of nodes which necessitates plurality of nodes described in col 6, lines 27-28);
determine, by the plurality of nodes that are part of the distributed blockchain ledger, that the first generated authentication credential has expired (Yang, Col. 10, lines 51-61, “The first terminal 10 requests deletion of metadata (551) … The management server 110 may verify the deletion message with a specific verification key” i.e., examiner interprets deletion necessitates expire credentials); and
in response (Yang, Col. 10, lines 51-54, “The first terminal 10 requests deletion of metadata (551). The first terminal 10 transmits a metadata deletion message to the management server 110 (552)”) to determining that the first generated authentication credential has expired, delete, or invalidate, by the plurality of nodes that are part of the distributed blockchain ledger, the first generated authentication credential (Yang, Col. 10, lines 62-67, “the management server 110 may authenticate the user who has transferred the deletion message (560). The authentication may be performed according to whether an authentication token transferred from the first terminal 10 is valid. The management server 110 transmits the deletion message to the metadata blockchain 140 (562)”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 10 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 11:
Method claim 11 corresponds to system claim 1 and contains no further limitations. Therefore, claim 11 is rejected for the reason set forth in the rejection of claim 1.
Regarding claim 12:
Method claim 12 corresponds to system claim 2 and contains no further limitations. Therefore, claim 12 is rejected for the reason set forth in the rejection of claim 2.
Regarding claim 13:
Method claim 13 corresponds to system claim 3 and contains no further limitations. Therefore, claim 13 is rejected for the reason set forth in the rejection of claim 3.
Regarding claim 14:
The method of claim 12, wherein Suzuki in view of Zappier further in view of Yang teaches the first generated authentication credential is generated based on a biometric of a user (Yang, Col. 6, lines 31-38, “The user information blockchain 120 stores a hash key for a user and user information… the user information may include the user's identifier, identity (ID), contact information, email address, name, sex, affiliated institution, birthdate, and the like. The user information blockchain 120 may have user information encrypted with a public key”).
The motivation for combining Yang to Suzuki to Zappier for the rejection of claim 14 is the same respective motivation applied to the rejection claim 1 above.
Regarding claim 15:
Method claim 15 corresponds to system claim 5 and contains no further limitations. Therefore, claim 15 is rejected for the reason set forth in the rejection of claim 5.
Regarding claim 16:
Method claim 16 corresponds to system claim and contains no further limitations 7. Therefore, claim 16 is rejected for the reason set forth in the rejection of claim 7.
Regarding claim 17:
Method claim 17 corresponds to system claim 8 and contains no further limitations. Therefore, claim 17 is rejected for the reason set forth in the rejection of claim 8.
Regarding claim 18:
Method claim 18 corresponds to system claim 9 and contains no further limitations. Therefore, claim 18 is rejected for the reason set forth in the rejection of claim 9.
Regarding claim 19:
Method claim 19 corresponds to system claim 10 and contains no further limitations. Therefore, claim 19 is rejected for the reason set forth in the rejection of claim 10.
Regarding claim 20:
Non-transitory computer readable medium claim 20 corresponds to system claim 1 and contains no further limitations. Therefore, claim 20 is rejected for the reason set forth in the rejection of claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Gnanasambandam et al., US 2025/0148465, disclosing Hyperledger rules for authentication based on type of transaction.
Barger et al., US 2022/0393858, disclosing the requirements of different verifiable credentials from users of a blockchain based on different types of transactions.
THIS ACTION IS MADE FINAL. 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 Rupal Dharia whose telephone number is (571)272-3880. The examiner can normally be reached M-F 8-5.
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.
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.
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492