DETAILED ACTION
1. This action is responsive to communication filed on 24 July 2026, with acknowledgement of an original application filed on 07 February 2025.
2. Claims 1-20 are currently pending. Claims 1 and 11 are in independent forms.
Drawings
3. The drawings filed on 02/07/2025 are accepted.
Response to Arguments
4. Applicant's arguments filed on 24 July 2026 have been fully considered but they are not persuasive.
I) In response to applicant's arguments on page 1, Applicants respectfully submit that Maycotte and Huang collectively do not disclose or suggest at least the features highlighted “receiving, by a data virtualization service executing on the data management service system from a requesting application, a data query processing request, the data query processing request comprising identification information and an indication of a virtual data set managed by the data virtualization service, the virtual data set being associated with data managed by one or more data source services”.
The examiner respectfully disagrees with the argument. The applicant argued that Maycotte and Huang collectively do not disclose or suggest an indication of a virtual data set managed by the data virtualization service, the virtual data set being associated with data managed by one or more data source services. Contrary to the applicant assertion, as stated in the office action the Maycotte reference discloses Query engine 314, in various embodiments, facilitates the execution of queries against the VDSs 120 that are managed by VDSM 130. Query engine 314 may receive, from a user or another entity via a query function of VDSM API 311, a data request that specifies one or more queries to be executed against one or more VDSs 120. Furthermore, the Maycotte reference discloses Method 700 begins in step 710 with the VDSM maintaining a virtual data source (VDS) registry (e.g., a VDS registry 320) for a plurality of virtual data sources (VDSs). The VDS registry may include, for a given one of the plurality of VDSs, VDS metadata (e.g., VDS metadata 230) that is indicative of data represented in a bitmap index (e.g., a data representation 210) included in that given VDS. In step 720, the VDSM receives a request for information (e.g., data request 425) stored in a set of original data sources (e.g., data sources 110) that correspond to the plurality of VDSs. In step 730, the VDSM processes the request against the plurality of VDSs without accessing the set of original data sources. In step 732, as part of the processing, the VDSM identifies, based on the VDS metadata, at least one of the plurality of VDSs having a bitmap index corresponding to the request (e.g., the VDS metadata indicates that its corresponding bitmap index stores information for a data field from which data is being requested). In step 734, as part of the processing, the VDSM sends, to the at least one VDS, one or more queries that are based on the request. (see Maycotte pars. 0113-0114, 0077, 0088).
II) In response to applicant's arguments on page 2, Applicants respectfully submit that Maycotte and Huang collectively do not disclose or suggest issuing the push down data query processing request to at least one data source service of the one or more data source services managing the at least a portion of the data.
The examiner respectfully disagrees with the argument. The applicant argued that Maycotte and Huang collectively do not disclose or suggest issuing the push down data query processing request to at least one data source service of the one or more data source services managing the at least a portion of the data. Contrary to the applicant assertion, as stated in the office action the Maycotte reference discloses access control engine 313 may include an access rule that indicates that user A can issue queries to a particular VDS 120 for data. That access rule may further indicate that user A can access only a subset of data of that particular VDS 120—e.g., user A can access data from columns 1-1000 of a bitmap index 210 included in the particular VDS 120. Furthermore, the Maycotte reference discloses VDSs 120A-C include data that is representative of data stored at data source 110, which is a SQL database in the illustrated embodiment. As shown, there is a change data capture (CDC) plugin (an example of an ingest plugin 224) that can ingest data from data source 110 and into VDS 120A-C. This may include updates received at the SQL database as part of its ingest pipeline. As further shown, VDSM 130 interfaces with an application and/or an AI engine (which may be an example of a consumption plugin 224) that issues requests for data to VDSM 130. VDSM 130 can execute queries derived from those requests against VDSs 120A-C to generate a result. VDSM 130 may then return that result to the application and/or AI engine (see Maycotte par. 0105). Contrary to the applicant assertion, as stated in the office action the Huang reference discloses intermediate query coordinators 920(1) through 920(n) may push down the query plan fragments and/or Bloom filters to a set of query agents 922(1) through 922(n) located in various remote data centers 928. Furthermore, the Huang reference discloses query optimizer 1104 may send the query portion directed to the warehouse data to a root layer 1106. In one embodiment, root layer 1106 may scan through the warehouse metadata for warehouse 1130 and generate a file descriptor for each portion of data. In some embodiments, leaf layer 1110 may be the layer loading the data from warehouse 1130 and applying operations (e.g., aggregating, filtering, etc.) to this data. In one embodiment, the systems described herein may include two layers of data operation in each leaf node within leaf layer 1110. In this embodiment, the first layer may directly access warehouse data files to retrieve uncompressed data and parse that data into multiple batches. In some embodiments, the first layer may support simple filtering, column projection, limited data operators, and/or limited user defined functions. In some embodiments, the second layer may take the output of the first layer and finalize the results. In one embodiment, to improve query speed, the systems described herein may push down filter operators, projection operators, limit operators, and/or other relevant operators into the first layer to trim data efficiently (see Huang pars. 0210-0212).
III) In response to applicant's arguments on page 2, Applicants respectfully submit that Maycotte and Huang collectively do not disclose or suggest receiving, from the at least one data source service of the one or more data source services associated with the virtual data set, a push down data query processing response generated in response to the push down data query processing request from the at least one data source service of the one or more data source services.
The examiner respectfully disagrees with the argument. The applicant argued that Maycotte and Huang collectively do not disclose or suggest receiving, from the at least one data source service of the one or more data source services associated with the virtual data set, a push down data query processing response generated in response to the push down data query processing request from the at least one data source service of the one or more data source services. Contrary to the applicant assertion, as stated in the office action the Maycotte reference discloses A VDS may be created by a VDSM in response to receiving a request via an application programming interface (API) of the VDSM. In some embodiments, the VDSM provides a user interface that enables a user such as a system administrator to select from various options when creating, copying, importing, or linking a VDS. Furthermore, the Maycotte reference discloses the VDSM manages a pool of resources by allocating resources (e.g., servers, nodes 145, storage devices, etc.) of the pool to the VDS and one or more services (e.g., VDSM API 311, user interface engine 312, etc.) maintained by the computer system. The VDSM may provide an application programming interface (API) (e.g., VDSM API 311) that permits an external entity (e.g., an application server) to issue requests to the VDSM to perform one or more functions (e.g., access data) in relation to the VDS. The API may include a delete function callable to cause the VDSM to delete a VDS, a list function callable to cause the VDSM to list VDSs managed by the VDSM, and/or a clone function callable to cause the VDSM to create a VDS by cloning another VDS. The VDSM may allocate at least one resource (e.g., a server) from the pool as an API server for implementing the API. In various cases, the VDSM may allocate at least one resource (e.g., a server) from the pool to a compute cluster for implementing the VDS—the compute cluster may implement a plurality of VDSs managed by the VDSM (see Maycotte par. 0111).
IV) In response to applicant's arguments on page 6, Applicants respectfully submit that Tamura's disclosure of transmitting an access request to a hot storage apparatus or a cold storage apparatus does not disclose or suggest the claim-recited push down query processing features recited in the claims identified above.
Examiner refer applicant to the response above in items I-III.
Claim Rejections - 35 USC § 103
5. 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.
6. Claims 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Maycotte et al. US Patent Application Publication No. 2021/03742663 (hereinafter Maycotte) in view of Huang et al. US Patent Application Publication No. 2021/0319130 (hereinafter Huang).
Regarding claim 1, Maycotte discloses a method for managing data performed by a data management service system, the method comprising:
“receiving, by a data virtualization service executing on the data management service system from a requesting application, a data query processing request, the data query processing request comprising identification information and an indication of a virtual data set managed by the data virtualization service, the virtual data set being associated with data managed by one or more data source services” (see Maycotte par. 0090, Query engine 314, in various embodiments, facilitates the execution of queries against the VDSs 120 that are managed by VDSM 130. Query engine 314 may receive, from a user or another entity via a query function of VDSM API 311, a data request that specifies one or more queries to be executed against one or more VDSs 120. In some cases, the one or more queries may be from a query language (e.g., SQL) that is different than the query language understood by VDSs 120 (e.g., the Pilosa Query Language). Accordingly, query engine 314 may translate the one or more queries into the query language that is understood by VDSs 120);
“generating, based on the data query processing request, (see Maycotte par. 0094, VDS registry 320, in various embodiments, stores information about the VDSs 120 that are managed by VDSM 130. This information may include the VDS metadata 230 from each of those VDSs 120—that is, VDS registry 320 may store a copy of the VDS metadata 230 of each VDS 120 managed by VDSM 130. As mentioned, query engine 314 may route queries to VDSs 120 that are identified based on information in VDS registry 320. In particular, in some cases, query engine 314 may access filter information 236 that is included in the VDS metadata 230 copies. As explained above, filter information 236 may identify a mapping between data fields of a VDS 120 and data fields of an underlying data source 110. As such, query engine 314 may determine which data fields are being accessed by a query and which VDSs 120 include those data fields based on filter information 236);
“issuing the (see Maycotte par. 0088, access control engine 313 may include an access rule that indicates that user A can issue queries to a particular VDS 120 for data. That access rule may further indicate that user A can access only a subset of data of that particular VDS 120—e.g., user A can access data from columns 1-1000 of a bitmap index 210 included in the particular VDS 120. When a request is received at VDSM 130 via VDSM API 311, in various embodiments, access control engine 313 checks the request against the list of users and approved actions to determine whether to permit the request to be processed);
“receiving, from the at least one data source service of the one or more data source services associated with the virtual data set, a (see Maycotte par. 0032, A VDS may be created by a VDSM in response to receiving a request via an application programming interface (API) of the VDSM. In some embodiments, the VDSM provides a user interface that enables a user such as a system administrator to select from various options when creating, copying, importing, or linking a VDS. For example, the user might select an original data source for the VDS from a list of data sources. The user interface may then send a request to create a VDS via the VDSM's API. In some embodiments, the request to create the VDS includes information that identifies a corresponding original data source and a configuration for ingesting data from that data source into the data structure (e.g., a bitmap index) of the VDS. Based on that information, the VDSM may instantiate an ingestion plugin that ingests data from the original data source into a format that can be stored in the data structure of the VDS); and
“transmitting a data query processing response to the requesting application, the data query processing response being generated based on the see Maycotte pars. 0046-0047, VDSM 130 may send a request to VDS 120A for data in its data representation. That request may include a query that is processed by the software routines of VDS 120A to return a response that includes the requested data. As discussed in more detail with respect to FIG. 2A, the software routines of a VDS 120 implement an API that allows for entities, such as VDSM 130, to send requests down to that VDS 120. In various embodiments, this API enables an ingestion routine (which may be initiated by VDSM 130) to push ingested data into the data representation of a VDS 120. A VDS 120 may include additional metadata to facilitate the flow of data into and out of the VDS 120. This metadata may include, for example, source information that identifies an underlying data source 110 (or another VDS 120) and authentication credentials for enabling access to data from that data source 110 so that it can be ingested into the data representation of the corresponding VDS 120);
Maycotte does not explicitly discloses a push down data query.
However, in analogues art, Huang discloses a push down data query (see Huang par. 0159, intermediate query coordinators 920(1) through 920(n) may push down the query plan fragments and/or Bloom filters to a set of query agents 922(1) through 922(n) located in various remote data centers 928. In one embodiment, any or each of query agents 922(1) through 922(n) may query a local metadata store 924 for more specific location information (e.g., rack, server, partition, etc.)).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Huang in to the system of Maycotte in order to include data arranged in locality domains, it may become possible to decompose a query plan into constituent fragments and to map those fragments over the locality domains via push down processing (see Huang par. 0153).
Regarding claims 2 and 12, Maycotte in view Huang the method of claim 1, the method of claim 11,
Maycotte further discloses wherein the method further comprises authenticating the data query processing request based, at least in part, on the identification information (see Maycotte par. 0047, A VDS 120 may include additional metadata to facilitate the flow of data into and out of the VDS 120. This metadata may include, for example, source information that identifies an underlying data source 110 (or another VDS 120) and authentication credentials for enabling access to data from that data source 110 so that it can be ingested into the data representation of the corresponding VDS 120).
Regarding claims 3 and 13, Maycotte in view Huang the method of claim 2, the method of claim 12,
Maycotte further discloses wherein authenticating the data query processing request comprises determining, by the data virtualization service, that the data query processing request should be granted (see Maycotte par. 0066, VDS API 222, in various embodiments, is an interface provided by VDS engine 220 to allow for entities (e.g., VDSM 130) that are outside of VDS 120 to access and manipulate the components within VDS 120. In various embodiments, VDS API 222 includes a set of query functions that are invokable to query data representation 210 for data).
Regarding claims 4 and 14, Maycotte in view Huang the method of claim 3, the method of claim 13,
Maycotte further discloses wherein determining that the data query processing request should be granted comprises: issuing, by the data virtualization service, an authentication query to an identity and access management service, the authentication query comprising the first identification information and the indication of the virtual data set, and receiving, from the identity and access management service in response to the authentication query, an indication granting the data query processing request (see Maycotte par. 0088, access control engine 313 may include an access rule that indicates that user A can issue queries to a particular VDS 120 for data. That access rule may further indicate that user A can access only a subset of data of that particular VDS 120—e.g., user A can access data from columns 1-1000 of a bitmap index 210 included in the particular VDS 120. When a request is received at VDSM 130 via VDSM API 311, in various embodiments, access control engine 313 checks the request against the list of users and approved actions to determine whether to permit the request to be processed. If the request is attempting to access data or perform an action that is not approved, then access control engine 313 may reject the request; otherwise, the request may be processed by VDSM 130).
Regarding claims 5 and 15, Maycotte in view Huang the method of claim 1, the method of claim 11,
Maycotte further discloses wherein the requesting application comprises an application executing on a user system, the user system being different than the data management service system (see Maycotte par. 0086, user interface engine 312 may send user interface information to a computer system of the user and that computer system may then present a user interface for creating/adding a VDS 120 based on the user interface information. The user may select a data source 110 (e.g., from a dropdown menu that includes a list of data sources 110), a location at which to store data of the VDS 120 (e.g., selected from another dropdown menu), a data format corresponding to the selected data source 110, etc. The user may further select plugins 224 from a list of plugins 224 to be used in relation to the VDS 120 being created).
Regarding claims 6, Maycotte in view Huang the method of claim 5,
Maycotte further discloses wherein the identification information comprises identification information associated with the user system (see Maycotte par. 0062, Record attributes may specify information associated with a record (column) that is not represented by a bit string. For example, email addresses are often unique values and as a result, it might not be desirable to represent them using a bit string; however, it may still be desirable to associate a record with an email address. As such, a record attribute may specify an email address for a record, such as the record corresponding to user A).
Regarding claim 7, Maycotte in view Huang the method of claim 5,
Maycotte further discloses wherein the identification information comprises identification information associated with a user of the user system (see Maycotte par. 0062, Record attributes may specify information associated with a record (column) that is not represented by a bit string. For example, email addresses are often unique values and as a result, it might not be desirable to represent them using a bit string; however, it may still be desirable to associate a record with an email address. As such, a record attribute may specify an email address for a record, such as the record corresponding to user A).
Regarding claims 8 and 17, Maycotte in view Huang the method of claim 1, the method of claim 11,
Maycotte further discloses wherein the identification information comprises identification information associated with the requesting application (see Maycotte par. 0104, VDSM 130 may receive queries from applications (via APIs or client libraries) for data stored at the original data sources 110. Instead of executing the queries against data source 110A and 110B, VDSM 130 may execute the queries against VDSs 120A and 120B. Accordingly, VDSM 130 may receive a result from VDSs 120A and 120B and return that result to the requesting process. In various cases, due to the structural nature of VDSs, executing the queries against VDSs 120A and 120B can be performed in a shorter amount of time relative to executing the queries against data sources 110A and 110B).
Regarding claims 9 and 18, Maycotte in view Huang the method of claim 1, the method of claim 11,
Maycotte further discloses wherein the requesting application comprises an application executing in a protected sandbox of a secure execution environment (see Maycotte par. 0056, Compute cluster 140 may be used to implement services of VDSM 130 (e.g., an API server) and a VDS environment having one or more VDSs 120. As shown, compute cluster includes nodes 145B-D. In various embodiments, a node 145 corresponds to a set of hardware processors, physical storage, network storage, and memory that is available to VDSM 130 for executing software routines and storing data. In some embodiments, a node 145 can be a virtual machine—this might provide VDSM 130 with less granular control than managing a set of hardware processors, storage, and memory. The resources of compute cluster 140 may correspond to resources that are managed by a different entity than the entity operating VDSM 130).
Regarding claims 10 and 19, Maycotte in view Huang the method of claim 9,
Maycotte further discloses wherein the secure execution environment comprises an execution environment of the data management service system (see Maycotte par. 0067, Plugins 224, in various embodiments, are sets of software routines that are executable to perform a specified set of operations in relation to VDS(s) 120 and/or VDSM(s) 130. Plugins 224 may generally fall within one of three types of categorizations (although, there are others): ingest plugins 224 that operate on data moving into VDS 120, consumption plugins 224 that operate on data moving out of VDS 120, and at-rest plugins 224 that operate on data at rest within VDS 120).
Regarding claim 11, Maycotte discloses a method for managing data performed by a data management service system, the method comprising:
“receiving, by a data virtualization service executing on the data management service system from a requesting application, a data query processing request, the data query processing request comprising identification information and an indication of a virtual data set managed by the data virtualization service” (see Maycotte par. 0090, Query engine 314, in various embodiments, facilitates the execution of queries against the VDSs 120 that are managed by VDSM 130. Query engine 314 may receive, from a user or another entity via a query function of VDSM API 311, a data request that specifies one or more queries to be executed against one or more VDSs 120. In some cases, the one or more queries may be from a query language (e.g., SQL) that is different than the query language understood by VDSs 120 (e.g., the Pilosa Query Language). Accordingly, query engine 314 may translate the one or more queries into the query language that is understood by VDSs 120);
“determining, by the data virtualization service based on the indication of the virtual data set, that a single data source (see Maycotte par. 0094, VDS registry 320, in various embodiments, stores information about the VDSs 120 that are managed by VDSM 130. This information may include the VDS metadata 230 from each of those VDSs 120—that is, VDS registry 320 may store a copy of the VDS metadata 230 of each VDS 120 managed by VDSM 130. As mentioned, query engine 314 may route queries to VDSs 120 that are identified based on information in VDS registry 320. In particular, in some cases, query engine 314 may access filter information 236 that is included in the VDS metadata 230 copies. As explained above, filter information 236 may identify a mapping between data fields of a VDS 120 and data fields of an underlying data source 110. As such, query engine 314 may determine which data fields are being accessed by a query and which VDSs 120 include those data fields based on filter information 236);
“retrieving, by the data virtualization service based on the determination, the first portion of data associated with the virtual data set from the first data store and the second portion of data associated with the virtual data set from the second data store” (see Maycotte par. 0032, A VDS may be created by a VDSM in response to receiving a request via an application programming interface (API) of the VDSM. In some embodiments, the VDSM provides a user interface that enables a user such as a system administrator to select from various options when creating, copying, importing, or linking a VDS. For example, the user might select an original data source for the VDS from a list of data sources. The user interface may then send a request to create a VDS via the VDSM's API. In some embodiments, the request to create the VDS includes information that identifies a corresponding original data source and a configuration for ingesting data from that data source into the data structure (e.g., a bitmap index) of the VDS. Based on that information, the VDSM may instantiate an ingestion plugin that ingests data from the original data source into a format that can be stored in the data structure of the VDS);
“transmitting the response to the requesting application” (see Maycotte pars. 0046-0047, VDSM 130 may send a request to VDS 120A for data in its data representation. That request may include a query that is processed by the software routines of VDS 120A to return a response that includes the requested data. As discussed in more detail with respect to FIG. 2A, the software routines of a VDS 120 implement an API that allows for entities, such as VDSM 130, to send requests down to that VDS 120).
Maycotte does not explicitly discloses push down query; generating a response to the data query processing request based on the retrieved first portion and second portion.
However, in analogues art, Huang discloses push down query (see Huang par. 0159, intermediate query coordinators 920(1) through 920(n) may push down the query plan fragments and/or Bloom filters to a set of query agents 922(1) through 922(n) located in various remote data centers 928. In one embodiment, any or each of query agents 922(1) through 922(n) may query a local metadata store 924 for more specific location information (e.g., rack, server, partition, etc.)); generating a response to the data query processing request based on the retrieved first portion and second portion (see Huang pars. 0209-0210, after query analyzer 1102 breaks the query into two portions, a query optimizer 1104 may further translate the warehouse portion of the query to leverage the warehouse index. Formulating a query to include partition columns may decrease response time because the search is not scanning the entire range of data, but only the specific portion that is relevant, query optimizer 1104 may send the query portion directed to the warehouse data to a root layer 1106. In one embodiment, root layer 1106 may scan through the warehouse metadata for warehouse 1130 and generate a file descriptor for each portion of data).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Huang in to the system of Maycotte in order to include data arranged in locality domains, it may become possible to decompose a query plan into constituent fragments and to map those fragments over the locality domains via push down processing (see Huang par. 0153).
Regarding claim 16, Maycotte in view of Huang discloses the method of claim 15, wherein the identification information comprises identification information associated with at least one of the user system and a user of the user system (see Maycotte par. 0062, Record attributes may specify information associated with a record (column) that is not represented by a bit string. For example, email addresses are often unique values and as a result, it might not be desirable to represent them using a bit string; however, it may still be desirable to associate a record with an email address. As such, a record attribute may specify an email address for a record, such as the record corresponding to user A).
7. Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Maycotte et al. US Patent Application Publication No. 2021/03742663 (hereinafter Maycotte) in view of Huang et al. US Patent Application Publication No. 2021/0319130 (hereinafter Huang) in further view of Tamura US Patent Application Publication No. 2014/0297947 (hereinafter Tamura).
Regarding claim 20, Maycotte in view of Huang discloses the method of claim 1, Maycotte in view of Huang does not explicitly discloses wherein the first data store comprises a cold data store and the second data store comprises a hot data store.
However, in analogues art, Tamura discloses wherein the first data store comprises a cold data store and the second data store comprises a hot data store (see Tamura Fig. 1, par. 0039, The storage apparatus 102 depicted in FIG. 1, stores based on the access time of each data among plural data stored by the storage system 100, the hot data as a first data group selected from the plural data. The storage apparatus 102 has the hot area 111 to store the hot data. The storage apparatus 103 depicted in FIG. 1 stores the cold data as a second data group exclusive of the hot data among the plural data. The storage apparatus 103 has the cold area 112 to store the cold data).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Tamura in to the system of Maycotte and Huang in order to efficiently perform data transfer at the time of relocation, it is better to separate the hot area and the cold area as employed by the second scheme and the third scheme. When the hot area and the cold area are separated, however, the system load is increased (see Tamura par. 0037).
Conclusion
8. 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 SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6:00 PM.
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, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/SAMUEL AMBAYE/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433
