DETAILED ACTION
Notice of 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 .
Status of the Application
Claims 1-20 were pending and were rejected in the previous office action. Claims 1, and 15 were amended. Claims 1-20 remain pending and are examined in this office action.
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 6/17/2026 has been entered.
Priority
This application claims the benefit of priority to U.S. Provisional Application No. 63/708,113, filed October 16, 2024.
Information Disclosure Statement
The Information Disclosure Statement filed 6/17/2026 has been considered.
Response to Arguments
35 USC § 101:
Applicant’s arguments regarding the previous § 101 rejection of claims 1-20 (pgs. 11-13, remarks filed 6/17/2026) have been fully considered and are persuasive.
Claims 1, 8 and 15 are amended to recite (using claim 1 as representative): enabling sharing of at least one of the activity feed or the activity report across accounts associated with the database, wherein the database is implemented using a block data model comprising multiple nested blocks, wherein the profile of the at least one contact is stored within a block of the multiple nested blocks, wherein each block of the multiple nested blocks includes an upward pointer that identifies a single parent block of the each block to provide a direct path from the each block to a root of the multiple nested blocks, and wherein the enabling sharing comprises traversing the upward pointer from the block storing the profile to the root of the multiple nested blocks to determine permissions for the accounts.
These limitations, considered as a whole, recite an inventive concept that amounts to an improvement to how computer databases store and retrieve data. As identified by applicant in the 6/17/2026 remarks, the specification identifies a specific technical problem and a specific technical solution. Paragraph [0033] explains that blocks are allowed to be referenced by multiple content arrays to simplify collaboration and a concurrency model. But because a block can be referenced in multiple places, it is ambiguous which block it would inherit permissions from. Paragraph [0033] further explains that trying to find this ancestor path by searching through all blocks' content arrays is inefficient, especially on the client. Instead, the model uses an upward pointer for the permission system. Amended claim 1 recites this very feature: each block of the multiple nested blocks includes an upward pointer that identifies a single parent block of each block to provide a direct path from each block to a root of the multiple nested blocks, and the enabling sharing comprises traversing the upward pointer from the block storing the profile to the root of the multiple nested blocks to determine permissions for the accounts. The amended claim therefore reflects the improvement disclosed in the Specification: using upward pointers to efficiently traverse from a block to the root for permission determination, rather than inefficiently searching through content arrays. This is analogous to the self-referential table structure in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016) which was determined to recite an improvement to computer functionality.
Therefore, the claims overcome the previous § 101 rejection (at least via Step 2A Prong Two) and are eligible under § 101. The previous rejection is withdrawn.
35 USC § 103:
Applicant’s arguments with respect to the § 103 rejections of claims 1-20 (pgs. 14-16, remarks filed 6/17/2026) have been considered but are moot, as they do not apply to the current grounds of rejection in the current § 103 rejections of claims 1-20 below, in response to applicant’s amendments.
Please see the current § 103 rejections over claims 1-20 below.
Claim Objections
Claims 1, 8 and 15 are objected to because of the following informalities:
Claims 1, 8 and 15 recite “an upward pointer that identifies a single parent block of the each block” which appears to be a typo that should read “an upward pointer that identifies a single parent block of each block”
Appropriate correction is required.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7-10, 12, 14-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160019661 A1 to Bouganim et al. (Bouganim) in view of NPL Reference U to “Teton-Landis” (see current PTO-892).
Note: NPL Reference U was retrieved from https://www.notion.com/blog/data-model-behind-notion and was Published on May 18, 2021, more than 1 year prior to the effective filing date of the instant application. Therefore, even though the reference appears to be published by the same entity as the applicant (Notion Labs, Inc.), it still qualifies as prior art over the instant application.
Claim 1: Bouganim teaches:
A computer-implemented method (Bouganim ¶ 0005-0026 showing computer implemented process steps; and ¶ 0049 “relationship management systems and methods for managing a social network in accordance with embodiments of the invention are disclosed”) comprising:
accessing a database storing a profile of at least one contact (Bouganim: ¶ 0056 showing accessing information for relevant contacts in a CRM database; also see ¶ 0005-0006, ¶ 0074, ¶ 0050-0051 and ¶ 0070),
wherein the database is integrated with electronic communication services (Bouganim: Figs. 1 and 2, ¶ 0069 showing data sources in communication with the relationship management server system, for collecting contacts information by the relationship management system, and storing the information on the contacts in database 34);
tracking interactions that include the at least one contact by logging electronic communications and events sent and received by the electronic communication services (Bouganim: ¶ 0005, ¶ 0026, ¶ 0068, ¶ 0073-0074 showing aggregating/obtaining even information, i.e. interactions, between the user and one or more contacts by monitoring sources of event information such as email, call records, meeting and calendar data, social networking communications, etc.);
determining a frequency of the interactions (Bouganim: ¶ 00060-0065, ¶ 0070 ¶ 0134 showing “The relationship management system may determine engagement scores with respect to achieving the objective (e.g., landing company B as a customer) based on the level of events between the set of users and the set of contacts. As described above, this scoring may take into account various factors, including the type of contact (e.g., title, position), the type of event (phone call, lunch meeting), the frequency of the event (e.g., how often people communicate), and the duration since the last event”);
generating a timeline of the interactions using the determined frequency of the interactions (Bouganim: Fig. 12, ¶ 0115 showing a timeline of interactions with a contact according to the collected events/interactions data, which displays frequency and shows how a relationship score decreases without contract over time, and showing the impact/effect of different events on a relationship score);
displaying an activity feed associated with the at least one contact, wherein the activity feed is generated using the timeline of the interactions (Bouganim: Fig. 17 and ¶ 0141 showing activity feed displayed on a contact page corresponding to a contact and showing a sequence of recent activity between the user and the contact “John Doe”, wherein “the UI displays a set of activities 1710. As described above, in some embodiments, these activities may be generated based on event information automatically captured and provided by a relationship management system,” i.e. based on a timeline of events over time captured as event information);
identifying patterns in the interactions using an artificial intelligence (AI) system (Bouganim: ¶ 0054 “relationship management systems use machine learning and statistical techniques to infer information from user networks and observed behaviors that can be used to enhance the ability of other users to achieve their objectives”; ¶ 0146 “In certain embodiments, machine learning techniques may be utilized to analyze data of contacts with which objectives have been successfully achieved, and based on this analysis, this relationship management system may provide recommendations and/or tasks for other contacts in order to achieve similar objectives. For example, if a certain level of event activity between a user and a contact has been achieved prior to a deal being reached in a majority of prior deals, then the relationship management system may use this historic information to determine when a current deal in progress and/or a future deal obtains the same requisite level of event activity to increase the likelihood of success of the deal”; note that one of ordinary skill in the art would know that machine learning to be a subset of artificial intelligence);
generating an activity report summarizing the patterns in the interactions (Bouganim: ¶ 0096-0098 and Fig. 9A, showing a generated user interface showing an overview summarizing the status of groups of contacts or with respect to specific tasks; also see groups such as recent contacts, frequently contacted, and 6+ months without contact),
wherein the activity report includes at least a date of a latest interaction involving the at least one contact (Bouganim Fig. 9A showing “Most recent contact: Today” for one group, with the other groups of contacts showing other dates of most recent contact);
enabling sharing of at least one of the activity feed or the activity report across accounts associated with the database (Bouganim: ¶ 0066 showing “the relationship management system may be used across many users (e.g., by management), and provide managers with administrative level access to tune the scored relationships held by different users with respect to contacts. For example, a user may engage another colleague to assist during a particular stage of a deal, and the colleague may fine tune the relationship scores based on their own subjective perceptions of the strengths of various relationships with contacts. In this way, the relationship management system can employ user feedback, from a user, other users, and or managers with administrative level access in order to increase the likelihood that the user's scored social graph closely corresponds to the relationships the user enjoys in the real world”; and see ¶ 0133 “a relationship management system in accordance with embodiments of the invention can be deployed across a workgroup or an enterprise to provide team benchmarking, and a tool to support collaborative networking or optimization of shard social networks for a group of users. For example, a team member can ascertain whether another team member has a sufficiently strong relationship with an individual to perform a desired action with respect to the individual (e.g. request a benefit or arrange a meeting that will strengthen both users' relationship with the contact). In addition, the relationship management system can provide an opportunity for an organization to monitor the progress of business development efforts”; also see for example Fig. 17 element 1720 and Fig. 18 element 1810, which displays John Doe’s and Jane Doe’s relationship scores with other users);
With respect to the following limitation, while Bouganim teaches providing permissions and access to contacts through a database (Bouganim: ¶ 0066, ¶ 0133, Figs. 17-18, and ¶ 0056 as above), but does not explicitly teach the following data structure implementation of the database to determine permissions. However, Teton-Landis teaches:
wherein the database is implemented using a block data model comprising multiple nested blocks (Teton-Landis: Pg. 2-3 showing block data model, with Pg. 4 showing “the block model also allows blocks to be nested inside of other blocks”; see Pg. 8 showing the data records may include users),
wherein each block of the multiple nested blocks includes an upward pointer that identifies a single parent block of the each block to provide a direct path from the each block to a root of the multiple nested blocks (Teton-Landis: Pgs. 3 and 6-7 showing the plurality of nested blocks use an upward pointer to identify a single parent block to provide a direct path from each block to the root of the multiple nested blocks),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the block data model implementation of Teton-Landis in the CRM system of Bouganim with a reasonable expectation of success of arriving at the claimed invention, with the motivation “to provide […] users with the ability to customize how their information is moved, organized, and shared” (Teton-Landis: Pg. 1) and “so only the right people can read it or change it” (Teton-Landis: Pg. 6).
Bouganim, as modified above (to incorporate the nested blocks structure as per Teton-Landis above), further teaches:
wherein the profile of the at least one contact is stored within a block of the multiple nested blocks (Bouganim: ¶ 0005-0006, ¶ 0059-0060, ¶ 0069-0070, ¶ 0095-0098, Fig. 9A, showing contacts stored in database as data records, i.e. data blocks, and also arranged in groups),
With respect to the following limitation, while Bouganim discusses permissions associated with user account as per above, Bouganim does not explicitly teach the use of an upward pointer traversed to the root of blocks for determining permissions. However, Teton-Landis teaches:
and wherein the enabling sharing comprises traversing the upward pointer from the block storing the profile to the root of the multiple nested blocks to determine permissions for the accounts (Teton-Landis: Pg. 6 showing “It’s also important to understand how this structure protects your information so only the right people can read it or change it” and Pg. 7 showing traversing the upward pointer from the nested blocks to determine permissions – “To implement permission checks for a block, we need to look up the tree, getting that block’s ancestors all the way up to the root of the tree (which is the workspace)… we use an “upward pointer”—the parent attribute—for the permission system”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the use of an upward pointer to determine permissions from a root of the nested blocks in the block data model implementation of Teton-Landis in the CRM system of Bouganim with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the limitations above.
Bouganim, as modified above, further teaches:
and providing, to at least one of the accounts, at least one suggestion generated by the Al system based on at least one of the activity feed or the activity report (Bouganim: ¶ 0146 showing “machine learning techniques may be utilized to analyze data of contacts with which objectives have been successfully achieved, and based on this analysis, this relationship management system may provide recommendations and/or tasks for other contacts in order to achieve similar objectives. For example, if a certain level of event activity between a user and a contact has been achieved prior to a deal being reached in a majority of prior deals, then the relationship management system may use this historic information to determine when a current deal in progress and/or a future deal obtains the same requisite level of event activity to increase the likelihood of success of the deal. In many embodiments, the relationship management system may generate task entities to provide to a CRM system that may be displayed within a task list by the CRM system”; also see ¶ 0095 “the relationship management system can provide relationship target recommendations based upon the user's priorities and/or a list of recommended activities with respect to specific contacts and/or groups of contacts related to achieving one or more specific objectives” and ¶ 0098 “Once groups are defined, the relationship management system can generate recommendations specific to the objectives of the group (whether relationship targets or project objectives) in addition to recommendations related to achieving target relationship scores”)
Claim 2: Bouganim/Teton-Landis teach claim 1. Bouganim, as modified above, further teaches:
comprising at least one of: tracking progress of transactions associated with the at least one contact (Bouganim: ¶ 0117 showing tracking progress towards a desired relationship objective, a group objective, and/or a goal; also see ¶ 0053-0054, Fig. 13B, ¶ 0127 showing tracking progress toward deal stages and/or progress of relationship with contact with respect to an objective); or linking the interactions to a visual pipeline interface displaying stages of the transactions (Bouganim: Figs. 9A-9C, ¶ 0096-0098 showing groups of contacts in various stages, such as "suspects," "prospects," "referral sources," and "current customers" along with current relationships status/stage such as "knows my name," "exchange info," "promotes me," and "recommends me," and showing a target status for building relationships with the contacts in the group; in addition, also see ¶ 0051-0055 progress towards an objective in each of multiple stages/sub-stages is tracked, in an example pertaining to sales deal stages; see ¶ 0055 specifically describing the stages)
Claim 3: Bouganim/Teton-Landis teach claim 1. Bouganim, as modified above, further teaches:
determining importance values for the at least one contact based on the patterns in the interactions (Bouganim: ¶ 0062, ¶ 0064, ¶ 0114-0116, ¶ 0135 showing determining importance of a relationship/contact based upon the received events information; also see ¶ 0077, ¶ 0080, ¶ 0082, ¶ 0097 user designated importance)
Claim 5: Bouganim/Teton-Landis teach claim 1. Bouganim, as modified above, further teaches:
comprising at least one of: integrating the activity feed with calendar services to track meeting attendance (Bouganim: ¶ 0049, ¶ 0052, ¶ 0059, ¶ 0061-0062, ¶ 0068, ¶ 0084, ¶ 0134 showing tracking occurrence of in-person meetings between user and one or more contacts and retrieving event/meeting information from calendar services);
monitoring electronic communication response times;
or determining engagement metrics based on the frequency of the interactions (Bouganim: ¶ 0134 “The relationship management system may determine engagement scores with respect to achieving the objective (e.g., landing company B as a customer) based on the level of events between the set of users and the set of contacts. As described above, this scoring may take into account various factors, including the type of contact (e.g., title, position), the type of event (phone call, lunch meeting), the frequency of the event (e.g., how often people communicate), and the duration since the last event”)
Claim 7: Bouganim/Teton-Landis teach claim 1. Bouganim, as modified above, further teaches:
wherein the suggestion includes at least one of a recommended follow-up timing or recommended actions (Bouganim: ¶ 0004 “analyze a user's social network and provide recommendations concerning actions the user can take to strengthen relevant relationships and achieve defined objectives…”; also see ¶ 0019, ¶ 0024, ¶ 0053-0054, ¶ 0059, ¶ 0098-0100, ¶ 0114-0117 showing recommendations, including recommended actions to strengthen or improve relationship)
Claim 8: See the rejection of claim 1 above disclosing analogous limitations. Bouganim further discloses: A non-transitory, computer-readable storage medium comprising instructions recorded thereon, wherein the instructions, when executed by at least one data processor of a computer system, cause the computer system to… (Bouganim: ¶ 0005 “a relationship management server system that includes a processor and memory containing software and a database that includes several contacts obtained from at least one source of contact information. In many embodiments, the software directs the processor in the relationship management server system to…”).
Claims 9/16: See the rejection of claim 2 above.
Claims 10/17: See the rejection of claim 3 above.
Claims 12/19: See the rejection of claim 5 above.
Claim 14: See the rejection of claim 7 above.
Claim 15: See the rejection of claim 1 above disclosing analogous limitations. Bouganim further discloses: A computer system (Bouganim: ¶ 0005 relationship management server system) comprising: at least one hardware processor (Bouganim: ¶ 0005 a processor); and at least one non-transitory memory storing instructions, which, when executed by the at least one hardware processor, cause the computer system to… (Bouganim: ¶ 0005 “a relationship management server system that includes a processor and memory containing software and a database that includes several contacts obtained from at least one source of contact information. In many embodiments, the software directs the processor in the relationship management server system to…”).
Claims 4, 6, 11, 13, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160019661 A1 to Bouganim et al. (Bouganim) in view of NPL Reference U to “Teton-Landis” (see current PTO-892), and further in view of US 20210224858 A1 to Khoury et al. (Khoury).
Claim 4: Bouganim/Teton-Landis teach claim 1. Bouganim further teaches:
comprising: chronologically organizing the interactions (Bouganim: ¶ 0041, ¶ 0115, Fig. 12 showing interactions organized chronologically; ¶ 0056, ¶ 0059-0060, ¶ 0068, ¶ 0074, ¶ 0078-0079, ¶ 0136-0141 showing the aggregation of event information, i.e. interactions for updating relationship with contact);
With respect to the following limitations, Bouganim/Teton-Landis do not explicitly teach, however, Khoury teaches:
filtering the interactions by type including electronic communications and events (Khoury: ¶ 0113, ¶ 0235, ¶ 0266 showing filtering communications/content by various types of filters); and
enabling comments and tags on the interactions to provide the activity feed (Khoury: ¶ 0094, ¶ 0114-0115, ¶ 0183, ¶ 0249, ¶ 0344-0345 showing each piece of content may be commented on, liked, or otherwise interacted with; and ¶ 0330 specifying “a tag may be generated for each content element of each post whereby a unique identifier may be associated with each piece of specific content. The tags may then be tracked and traced so that the system can identify the exact history of every post containing that content, from which locations and in which contexts it has been employed, where and when it has been published, and the amount of engagement it has generated”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included filtering interactions by communication type and providing communications content that allows for commenting and tagging on social media platforms of Khoury in the relationship management system of Bouganim/Teton-Landis with a reasonable expectation of success of arriving at the claimed invention, with the motivation to provide “an intuitive, easy to use platform for advertisement generation and deployment across social media modalities and throughout the various divisions of global brands” and “to ensure message consistency, vastly increasing reach across social media modalities, while reducing production cost, thereby allowing a greater portion of advertising spend to be allocated to increasing reach and lift while reducing production costs” (Khoury: ¶ 0016).. Furthermore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 6: Bouganim/Teton-Landis teach claim 1. With respect to the following limitations, Bouganim teaches events information stored in a database, i.e. “activity feed is stored within multiple blocks, wherein each block represents an activity” (Bouganim: ¶ 0069-0070, ¶ 0074 showing collecting events/activity information and storing in database of the CRM/server system), but Bouganim/Teton-Landis do not explicitly teach the following limitations as a whole. However, Khoury teaches:
wherein the activity feed is stored within multiple blocks, wherein each block represents an activity (Khoury: ¶ 0127 showing structured database wherein each communication or instance of generated content and communications is stored in the database wherein “a unique identification may be generated for the communication and/or its components and used for cataloging the content and communication for storage”), and
wherein the method comprises enabling commenting and tagging on the blocks (Khoury: ¶ 0094, ¶ 0114-0115, ¶ 0183, ¶ 0249, ¶ 0344-0345 showing each piece of content, i.e. each data “block,” as a post/content that may be commented on, liked, or otherwise interacted with; and ¶ 0330 specifying “a tag may be generated for each content element of each post whereby a unique identifier may be associated with each piece of specific content. The tags may then be tracked and traced so that the system can identify the exact history of every post containing that content, from which locations and in which contexts it has been employed, where and when it has been published, and the amount of engagement it has generated”) while maintaining security boundaries between blocks using a hierarchical permission structure (Khoury: ¶ 0298 “the present communications platform allows various users within an organization, with the appropriate permissions and authorizations, to access all of the official social media interfaces of all of the retail outlets from the corporate to the local levels, and to manage the messaging taking place there on at a single or multiple client computing devices. For instance, at the corporate level, the maximum authorization may be permitted such that global access is allowed, whereas at the group or regional level only a subset of accesses are permitted, and then at the local level, access may only be given to the local franchisee's social media pages at one or more specific locations servicing a local community”; also see ¶ 0310, ¶ 0145 hierarchical permissions)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the database storing each piece of content, which is enabled for commenting and tagging on social media platforms of Khoury in the relationship management system of Bouganim/Teton-Landis with a reasonable expectation of success of arriving at the claimed invention, with the motivation to provide “an intuitive, easy to use platform for advertisement generation and deployment across social media modalities and throughout the various divisions of global brands” and “to ensure message consistency, vastly increasing reach across social media modalities, while reducing production cost, thereby allowing a greater portion of advertising spend to be allocated to increasing reach and lift while reducing production costs” (Khoury: ¶ 0016). Furthermore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim Interpretation Note: The filed specification at ¶ 0027 describes data blocks as follows: “The blocks are dynamic units of information that can be transformed into other block types and move across workspaces. The block model allows users to customize how their information is moved, organized, and shared. Hence, blocks contain information but are not siloed. [0028] Blocks are singular pieces that represent all units of information inside an editor. In one example, text, images, lists, a row in a database, etc., are all blocks in a workspace.” Therefore, the blocks describe units of information.
Claims 11/18: See the rejection of claim 4 above.
Claims 13/20: See the rejection of claim 6 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 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, Shannon Campbell can be reached at (571) 272-5587. 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.
/HUNTER MOLNAR/Examiner, Art Unit 3628
Prosecution Insights