DETAILED ACTION
This Office Action is in response to Applicant's response to application filed on 25 June 2025. Currently, claims 1-20 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are clearly drawn to at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. 101 (apparatus, method and computer program product). Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 1, 8 and 15 recite the abstract idea of receiving an allocated support seeker request from a support provider wherein the allocated support seeker request comprises at least one of an allocated support seeker organization request or an allocated support seeker contact request and accessing one or more support seeker data objects from an asset-based data tracking system based on the allocated support seeker request and causing generating an allocated support seeker overview wherein the allocated support seeker overview comprises at least one of an allocated support seeker organization overview or an allocated support seeker contact overview. The claims are directed to a type of generating overviews based on support requests. Under prong 1 of Step 2A, these claims are considered abstract because the claims are certain methods of organizing human activity including commercial interactions such as business relations. Applicant’s claims show an overview is a type of organization of the support requests which are human interactions related to business relations. Under prong 2 of Step 2A, the judicial exception is not integrated into a practical application because the claims (the judicial exception and any additional elements individually or in combination such as an apparatus comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus to perform steps, computer-implemented method, a computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising an executable portion configured to perform steps, a visualization request, computing device, wherein each of the one or more support seeker data objects comprises support seeker context metadata, overview user interface based at least in part on the support seeker context metadata are not an improvement to a computer or a technology, the claims do not apply the judicial exception with a particular machine, the claims do not effect a transformation or reduction of a particular article to a different state or thing nor do the claims apply the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment such that the claims as a whole is more than a drafting effort designed to monopolize the exception. These limitations at best are merely implementing an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as an apparatus comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus to perform steps, computer-implemented method, a computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising an executable portion configured to perform steps, a visualization request, computing device, wherein each of the one or more support seeker data objects comprises support seeker context metadata, overview user interface based at least in part on the support seeker context metadata (as evidenced by para [0036], [0047], [0056]-[0061], [0081]-[0112] of applicant’s own specification) are well understood, routine and conventional in the field. Dependent claims 4, 7, 11, 14, 18 also do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements either individually or in combination are merely an extension of the abstract idea itself by further showing in response to receiving a user selection input associated with the allocated organization, generating an allocated organization context detail and in response to receiving a user selection input associated with the allocated contact name portion, cause generating an allocated contact context detail. Dependent claims 2-7, 9-14, 16-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as wherein the allocated support seeker overview user interface comprises the allocated support seeker organization overview user interface, wherein the allocated support seeker organization overview user interface comprises an allocated organization tabular user interface component and wherein the allocated organization tabular user interface component comprises an allocated organization name metadata portion and an allocated organization domain metadata portion and generating an allocated organization context detail user interface and wherein the allocated support seeker overview user interface comprises the allocated support seeker contact overview user interface, wherein the allocated support seeker contact overview user interface comprises an allocated contact tabular user interface component and wherein the allocated contact tabular user interface component comprises an allocated contact name metadata portion and an allocated contact email metadata portion (as evidenced by para [0036], [0047], [0056]-[0061], [0081]-[0112] of applicant’s own specification) are well understood, routine and conventional in the field.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 8-12, 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ashby (US 2023/0289817 A1) (hereinafter Ashby).
Claims 1, 8 and 15:
Ashby, as shown, discloses the following limitations of claims 1, 8 and 15:
An apparatus (and corresponding computer-implemented method and non-transitory computer readable medium - see para [0136]-[0137] and Fig 1 showing equivalent computer functionality) comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus (see para [0136]-[0137] and Fig 1 showing equivalent computer functionality ) to at least: receive an allocated support seeker visualization request from a support provider computing device, wherein the allocated support seeker visualization request comprises at least one of an allocated support seeker organization visualization request or an allocated support seeker contact visualization request (see para [0021], "Systems and methods for enabling a person who is experiencing and interacting in a virtual environment to obtain customer support or other form of assistance within the environment for an object, service, or experience they interact with in the virtual environment. In some embodiments, this may include the option of obtaining support or a form of assistance from avatars or objects in the virtual environment. In one embodiment, this may be enabled by converting or transforming a request for assistance into an object (referred to as a support request object herein) in the virtual environment." and see para [0102]-[0113]);
access one or more support seeker data objects from an asset-based data tracking system based on the allocated support seeker visualization request, wherein each of the one or more support seeker data objects comprises support seeker context metadata (Fig 1B showing the request for assistance is transferred to the support provider entity and see para [0101]-[0113], showing metadata includes metadata for establishing privileges with the product for which assistance is requested); and
cause generating an allocated support seeker overview user interface based at least in part on the support seeker context metadata, wherein the allocated support seeker overview user interface comprises at least one of an allocated support seeker organization overview user interface or an allocated support seeker contact overview user interface (see para [0191], "In some embodiments, one or more of the modules used to determine if support is needed (or the customer support module) may generate a user interface 109 within the virtual or augmented reality environment to enable avatar 103 to interact with customer support services. Interface 109 may include selectable or activatable elements that avatar 103 may use to indicate a product (such as by model or generic category) or type of service for which assistance is desired, the type of assistance desired, or another aspect of a service request." where it is obvious to one of ordinary skill in the art that user interface generated in a virtual or augment augmented environment that provides customer support can be considered support seeker context metadata, based on the environment and see para [0161], "In some embodiments, to provide “contextual” based customer support in a virtual world for a virtual product or virtual service may involve implementation of one or more of the following functions or capabilities")
Claims 2, 9 and 16:
Further, Ashby discloses the following limitations:
wherein the allocated support seeker overview user interface comprises the allocated support seeker organization overview user interface, wherein the allocated support seeker organization overview user interface comprises an allocated organization tabular user interface component (Figs 1, 5, showing UI elements can be organized in a tabular way and see para [0305], “Examples of graphical user interface elements include buttons, menus, checkboxes, drop-down lists, scrollbars, sliders, spinners, text boxes, icons, labels, progress bars, status bars, toolbars, windows, hyperlinks, and dialog boxes. Application programming interfaces may be local or remote and may include interface elements such as a variety of controls, parameterized procedure calls, programmatic objects, and messaging protocols.”)
Claims 3, 10 and 17:
Further, Ashby discloses the following limitations:
wherein the allocated organization tabular user interface component comprises an allocated organization name metadata portion and an allocated organization domain metadata portion (see para [0278], "FIG. 3 is a diagram illustrating a system 300 in which an embodiment may be implemented or through which an embodiment of the services disclosed and/or described herein may be accessed. In accordance with the advantages of an application service provider (ASP) hosted business service system (such as a multi-tenant data processing platform), users of the services disclosed and/or described may comprise individuals, businesses, brands, stores, or organizations, as non-limiting examples. A user may access the services using a suitable client, including but not limited to desktop computers, laptop computers, tablet computers, scanners, smartphones, or dedicated VR headsets, for example. In general, a client device having access to the Internet may be used. A user interfaces with the service platform across the Internet 308 or another suitable communications network or combination of networks. Examples of suitable client devices include desktop computers 303, smartphones 304, tablet computers 305, or laptop computers 306." and see para [0300], "The user interface tier 416 may maintain multiple user interfaces 417, including graphical user interfaces and/or web-based interfaces. The user interfaces may include a default user interface for the service to provide access to applications and data for a user or “tenant” of the service (depicted as “Service UI” in the figure), as well as one or more user interfaces that have been specialized/customized in accordance with user specific requirements (e.g., represented by “Tenant A UI”, . . . , “Tenant Z UI” in the figure, and which may be accessed via one or more APIs)." and Figs 4-5, where it is obvious to one of ordinary skill in the art that the service and tenants describing businesses, brands, stores or organizations can be considered the name and domain metaportions given broadest reasonable interpretation)
Claims 4, 11 and 18:
Further, Ashby discloses the following limitations:
wherein the at least one non-transitory memory and the program code are configured to, with the at least one processor, cause the apparatus to: in response to receiving a user selection input associated with the allocated organization name metadata portion, cause generating an allocated organization context detail user interface (see para [0089], "In response to the request, identify the product or service for which assistance is requested and determine if the avatar (and by inference, the real-world person/user corresponding to the avatar) is authorized to obtain the requested assistance. This step or stage of the process may be optional, and used as a gating step to verify that an avatar (and by inference the real-world person) is authorized to receive the product or service assistance, and therefore to participate in the conversion and transfer of a support object" and see para [0098], " a support request object may be created as part of a Decentralized Autonomous Organization (DAO) where there the support object would be referenced, managed, and made secure. This process would include providing links to where the support details are stored in any corresponding integrated support services" and see para [0180], " Each object would be expected to have different support needs and different contextual information, and a support platform needs to be able to distinguish between each object and enable a user to receive support services applicable to that object from its associated source or brand.")
Claims 5, 12 and 19:
Further, Ashby discloses the following limitations:
wherein the allocated support seeker overview user interface comprises the allocated support seeker contact overview user interface, wherein the allocated support seeker contact overview user interface comprises an allocated contact tabular user interface component (Figs 1, 5, showing UI elements can be organized in a tabular way and see para [0305], “Examples of graphical user interface elements include buttons, menus, checkboxes, drop-down lists, scrollbars, sliders, spinners, text boxes, icons, labels, progress bars, status bars, toolbars, windows, hyperlinks, and dialog boxes. Application programming interfaces may be local or remote and may include interface elements such as a variety of controls, parameterized procedure calls, programmatic objects, and messaging protocols.”)
Claims 6-7, 13-14, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ashby, as applied above, and further in view of Roberts et al. (US 20160132960 A1) (hereinafter Roberts)
Claims 6-7, 13-14 and 20:
Ashby does not specifically disclose an allocated contact email metadata portion. In analogous art, Roberts discloses the following limitations:
wherein the allocated contact tabular user interface component comprises an allocated contact name metadata portion and an allocated contact email metadata portion (see para [0045], "FIG. 4 is a flowchart of an illustrative method 400 for displaying aggregated information from a plurality of business applications on a centralized dashboard user interface screen (e.g., the client centric view user interface screen) according to one or more aspects of the present disclosure. At 410, the client viewer 310 may receive a request to view information corresponding to a particular client. For example, a financial advisor may access a client request user interface screen to enter a customer identifier (e.g., a name, an account number, a phone number, an email address, and the like) associated with a particular customer. At 420, the client viewer 310 may obtain information corresponding to the particular customer. For example, the client viewer 310 may query one or more of the business function computer systems 320, 330 for information associated with the received customer identifier. In some cases, information stored in the local data repository may be overwritten and/or supplemented with new data received from one or more of the business function computer systems 320, 330. Such information may include a plurality of consumer contacts (e.g., phone calls, emails, letters, web page views, and the like), times of such contact, account information, account balances, subscribed products, and the like. At 425, the client viewer 310 may check to see whether the last relevant computing systems have been contacted. If not, a next business computing system may be contacted at 420 to obtain information corresponding to the user identifier.” and see para [0025])
in response to receiving a user selection input associated with the allocated contact name metadata portion, cause generating an allocated contact context detail user interface (see para [0045]-[0046], especially "If information has been received from the last business computing system, the client viewer 310 may analyze the obtained information. In some cases, the client viewer may provide information to and/or receive analyzed information from the business analytics computing system 340. In other cases, the client viewer 310 may be configured to perform similar analytics to those done by the business analytics computing system. For example, the client viewer 310 may analyze account information (e.g., balances, holdings, and the like) associated with banking and/or brokerage accounts held by a customer. If a threshold condition (e.g., minimum account balance amounts, or the like) has been met, the client viewer 310 may indicate that an opportunity exists for the consumer to open a combined brokerage and banking account. In some cases, the client viewer may analyze information associated with retirement, or other such accounts, along with applicable government regulations, to determine whether a required minimum distribution (RMD) may be required to be taken before a specified date. In some cases, the client viewer 310 may analyze one or more accounts to determine whether one or more features have been utilized by the customer. For example, the client viewer may identify that the customer has one or more banking or brokerage accounts, but is not taking advantage of one or more products or services associated with those accounts. For example, the client viewer may identify that a customer is not enrolled in, or is not meeting a minimum requirement associated with, a particular service. For example, the client viewer may identify that a consumer has not enrolled, or is not meeting a minimum requirement associated with a direct deposit service and/or a funds transfer service.")
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to combine the teachings of Ashby with Roberts because including a contact email enables more effective communications about the applications ad services between customers and companies (see Roberts, para [0001]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the client view computing system as taught by Roberts in the system for providing decentralized support services in a virtual environment as taught by Ashby 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bellini et al. (US 8,996,642 B1), a system for facilitates servicing information technology support tickets that includes a server configured to access a database storing two support tickets, each of which can have a ticket identifier and information to facilitate providing information technology support to a computing device
Leslie et al. (AU 2014334515 A2), a system for enabling a job seeker to browse a plurality of job classifieds or a job provider to browse a plurality of job seeker profiles that includes generating and storing a job seeker profile for the job seeker based upon job seeker information a location of the job seeker; identifying a plurality of job classifieds stored in the data store which are relevant to the job seeker based upon the job seeker profile; serving the plurality of job classifieds to the mobile device for presentation to the job seeker; receiving job seeker feedback data indicative of whether each job classified was relevant or not relevant; analysing the job seeker feedback data; and updating the job seeker profile stored in the data store in accordance with the analysis of the job seeker feedback data.
Ajax et al. "Enhancing Business Intelligence with Data Visualization Tools", a paper on the adoption of data visualization tools that empowers organizations to make faster, more informed decisions, improving overall efficiency and competitiveness in the digital landscape
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUJAY KONERU whose telephone number is 571-270-3409. The examiner can normally be reached on Monday-Friday, 9 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia Munson can be reached on 571- 270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SUJAY KONERU/
Primary Examiner, Art Unit 3624
Prosecution Insights