DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
Claims 1-10, 12 and 14-19 were previously pending and subject to a final office action mailed 02/13/2026. Claims 1, 12 and 17 were amended; no claim was cancelled, or added in a reply filed 05/04/2026. Therefore claims 1-10, 12 and 14-19 are currently pending and subject to the non-final office action below.
Response to Arguments
Applicant's arguments filed 05/04/2026 in regards to section 101 rejection have been fully considered but they are not persuasive.
Applicant argues “Applicant submits that the features of the independent claims cannot be considered as falling within the Organizing Human Activity grouping at least because the claimed subject matter is not a technique for managing personal behavior or relationships or interactions between people. For example, the claims are directed to a method and system for connecting multiple components via an integrated delivery platform to exchange component data and API data with the multiple components via a plurality of API endpoints, execute a workflow via the exchanging of API data between a backend server component and an application workflow component to output data, automatically update a file via the exchange of API data, generate a report for the updated file, identify a validation flag during generation of the report, generate a validation request for validation of the generated report, receive selection of an embedded report link in the validation request, generate the report in response to the received selection, and publish the report after validation. At least these claimed features are not a technique for managing personal behavior or relationships or interactions between people (they are technological activities) nor are they a commercial or legal interaction, nor a fundamental economic practice.” (remarks p. 10-11).
Examiner respectfully disagrees. The claim is not characterized as abstract merely because it recites business terminology or because it involves enterprise software. Rather, the claim considered as a whole, recites managing an enterprise workflow for updating stored information, generating a report, routing the report for validation, receiving selection of a report link, and publishing the report after validation. These operations correspond to organizing and managing a report-review/publishing process and to collecting, updating, reviewing, presenting, and disseminating information.
The additional recitation that these operations are performed using an application workflow component, database storage component, application development component, directory-based identity related services component, integrated delivery platform, API endpoints, backend server, communication port, graphical user interface, and distributed communication network does not remove the claim from the abstract idea analysis. The claim uses these components as tools to automate the underlying report validation and publishing workflow. The claim does not recite a specific new API protocol, a specific new authentication algorithm, a specific new security token structure, a specific improvement to API endpoint operation, or a specific improvement to network communication. Instead, the claim recites the desired result of exchanging API data, confirming security, updating files, generating reports, requesting validation, and publishing reports. Accordingly, the claim recites an abstract idea under step 2A, Prong One.
Applicant argues “Rather, the claims recite interactions among electronic devices that enable the transfer of data such that multiple components are connected via API endpoints to provide a standardized connection between components at least with respect to security and reporting. This type of method is akin to computer programming, and is in the field of operation of electronic computing, which is not a technique for managing personal behavior or relationships or interactions between people. Therefore, the limitations of the independent claims are not directed to a judicial exception under Prong One.” (remarks p. 11).
Examiner respectfully disagrees. Merely reciting interactions among electronic devices, API endpoints, data transfer, and computer programming does not establish that the claim avoids an abstract idea. The relevant inquiry is not whether computers are involved, but whether the claim recites a judicial exception and, if so, whether the additional limitations integrate that exception into a practical application. Here, the claimed interactions among the electronic components are recited at a high level of generality. The claim does not define how the integrated delivery platform technically standardizes security beyond connecting components and exchanging API data after confirmation of security with a directory-based identity related services component. the claim also does not recite any particular technical improvement in how API endpoints are generated, secured, authenticated, authorized, etc…. the recited directory-based identity related services component performs the conventional functions of authenticating, authorizing, assigning and enforcing policies. The recited integrated delivery platform performs the conventional function of connecting components and exchanging data through API endpoints.
Thus, the claim does not recite a specific technological solution in the field of computer networking or API security. It recites the use of generic computer components to implement the abstract workflow.
Applicant argues “As described in Applicant's specification, an enterprise may have many different platforms and/or applications that are accessed by thousands of users, and the features across the platforms and/or applications may not be consistent and may make it difficult to communicate between the different platforms and/or applications. For example, separate security authorizations need to be created between component A and component B, and component A and component C, making it more difficult to communicate. See, e.g., paras. [0002] and [0026] of Applicant's specification.
To address these problems, embodiments provide an integrated delivery tool to facilitate security features across multiple platforms. The integrated delivery tool may connect multiple components via API endpoints to provide a standardized connection between components at least with respect to security. For example, instead of creating separate security and authorizations between component A and component B, and component A and component C, each component is connected to the integrated delivery tool, and the integrated delivery tool provides for the security authorizations between the components. API endpoints allow the data to be seamlessly exchanged without having to set up each individual component to be able to interact with the other components. For example, the integrated delivery platform standardizes the security for all the different components via application of the directory-based identity-related services component. The directory-based identity-related services authenticates and authorizes computers in a network, as well as assigns and enforces security policies. As the request and data pass through the integrated delivery platform, the integrated delivery platform confirms the security of the requests/data with the directory-based identity-related services component. This is in contrast to conventional systems where each component has its own security protocol.” (remarks p. 12).
Examiner respectfully disagrees. Although the specification may describe difficulties associated with multiple platforms, inconsistent applications, and separate security authorizations, the claim does not recite a particular technical way of solving those problems. The claim broadly recites that the integrated delivery platform connects multiple components and exchanges component data and API data via API endpoints, and that the exchange component data and API data via API endpoints, and that the exchange occurs in response to confirmation of security with the directory-based identity related services component. the claim does not recite how the security confirmation is technically performed, how separate security authorization are technically replaced, how credentials or permissions are transformed, how API endpoints calls are reduced, how latency is improved.
Furthermore, the claim does not recite a specific structure or algorithm by which the integrated delivery platform provides standardized security authorizations. The claim broadly requires connection of multiple components and exchange of component data and API data via API endpoints, with the exchange occurring in response to confirmation of security by a directory-based identity related services component. This is stated at the level of a desired functional result.
The recited “integrated delivery platform” is not claimed as a particular improves security architecture. The claim does not recite a new authorization protocol, new credential exchange, new token management technique, new API gateway security mechanism, or new enforcement structure. Rather, the claim invokes a generic platform and generic API endpoints to perform the abstract workflow more efficiently in a computer environment. Such use of conventional computer components does not integrate the judicial exception into a practical application.
The claim recites that the integrated delivery platform exchanges API data and that the exchange occurs in response to confirmation of security with directory-based identity related services component. However, the claim does not recite the alleged “seamless” exchange in a technically specific manner. Nor does the claim recite how requests and data are transformed, authenticated, authorized, routed or secured in a way that improves computer functionality.
The claimed directory-based identity related services component performs known identity service functions: authenticate, authorize, assign policies, and enforce policies. The claimed API endpoints perform known API functions: allowing components to exchange data. The claimed integrated delivery platform performs known middleware/integration functions: connecting components and exchanging data. Reciting these known components together to implement a report workflow does not amount to a specific improvement to computer technology.
Applicant argues “Pursuant to embodiments, security confirmation of data is performed via validation flags provided during report creation. The report may be automatically published to a user unless the report has been flagged during creation of the report as needing validation by the report publisher. In a case validation is required for a report, the user will not see the refreshed report until it is published. As part of the validation, the publisher may manually review the results/report and then publish the latest version of the result/report. The publisher may receive notification that a report was executed and needs to be validated. The notification may include an embedded report name link, a report type, an embedded report link, an embedded key contact link, and an embedded publisher link. Selection of the embedded report link may result in generation, by the email server, of an email message that includes the report.” (remarks p. 13).
Examiner respectfully disagrees. The claim recited validation steps are part of the abstract report review and publication workflow. Identifying a validation flag, generating a validation request, receiving selection of a report link, presenting the report to a publisher, and publishing after validation amount to routing information for review and approval before publication. These are administrative review and approval steps implemented using generic computer components.
The claim does not recite a particular technical way in which the validation flag improves security. The claim does not recite that the validation flag encrypts the report, changes access control lists, revokes access, prevents malware propagation, authenticates the publisher suing a new protocol, generates a time limited link, prevents unauthorized report rendering, or enforces a specific security policy. The claim merely requires that the report is published after validation by the report publisher. Accordingly, the validation limitations do not provide at technological improvement. They automate a review process using conventional computer functions.
Applicant argues “At least instructions to cause the computer processor to: "identify a validation flag during generation of a first report of the at least one report; generate, in response to the identified validation flag, a validation request for validation of the generated first report; receive a selection of an embedded report link in the validation request; in response to the received selection, generate the generated first report in the validation request to the report publisher; publish the first report after the first report is validated by the report publisher," as now claimed, increases the security for the components…As understood by a person of ordinary skill in the art, generating a report via an embedded link rather than an attachment, for example, is a practical application that is more secure because it enables real-time access control, allows revocation of access, prevents malware propagation from malicious files, and ensures users always view the most up-to-date, authenticated version.” (remarks p. 13).
Examiner respectfully disagrees. The quoted claim language does not recite how security for the components is increased. The claim recites a validation workflow associated with a generated report. The claim does not recite any technical operation performed on the components themselves to increase security. Nor does the claim recite any specific change to authentication, authorization, access control enforcement, API permissions, API endpoint security, network communication, encryption, etc…
The assertion that the claimed sequence “increases the security for the components” is not supported by corresponding technical limitations in the claim. The claim at most restricts publication of a report until a publisher validates the report. That is an approval condition for publication, not a claimed technical improvement to component security.
Furthermore, the claim does not recite the asserted technical features. The claim recites “receive a selection of an embedded report link in the validation request” and “in response to the received selection, generate the generated first report in the validation request to the report publisher” The claim does not recite generating a report via an embedded link rather than an attachment. The claim also does not recite real time access control, revocation of access, malware prevention, authentication of the displayed report version, link expiration, permission checking upon link selection, or ensuring that the report is the most up to date version.
Therefore, Applicant’s asserted security benefits are not commensurate in scope with the claim. The claim broadly covers selecting an embedded report link and generating the report in response. Without claiming the specific access control, revocation, or version control mechanisms, the embedded link limitation does not establish integration into a practical application.
Applicant argues “Additionally, Applicant notes Cosmokey Solutions GMBH & Co. v. Duo Security LLC (CAFC Case: 20-2043, October 2021). In a similar situation, the Court reversed a lower Court's finding that claims were ineligible for patent prosecution under 35 USC § 101 holding: ("[t]he specification explains that these features in combination with the other elements of the claim constitute an improvement that increases computer and network security, prevents a third party from fraudulently identifying itself as the user, and is easy to implement and can be carried out even with mobile devices of low complexity...Here, as the specification itself makes clear, the claims recite an inventive concept by requiring a specific set of ordered steps that go beyond the abstract idea identified by the district court and improve upon the prior art by providing a simple method that yields higher security.") (Page 14). The current Specification provides abundant details about the improvements provided by various claimed embodiments of the invention..." See, e.g., Page 13 of the Court's holding on Cosmokey. Similar to Cosmokey, the current claims describe only publishing a report with a validation flag after it has been validated, and as part of the validation, a validation request includes an embedded link that when selected generates the report in a user interface.” (remarks p. 13-14).
Examiner respectfully disagrees. CosmoKey is distinguishable. The claims in CosmoKey were directed to a specific computer implemented authentication technique that improved security by requiring a particular ordered authentication process involving activation of an authentication function, communication within a specific time period, and deactivation of the authentication function. The eligibility finding was based on the specific ordered steps that improved a particular authentication process. By contrast, the present claim does not recite a specific improved authentication technique. The claim recites generic directory-based identity related services that authenticate and authorize computers, assign and enforce security policies, and confirm security before API data exchange. The claim further recites a report validation workflow in which a validation flag is identified, a validation request is generated, an embedded report link is selected, and the report is published after validation. These limitations do not recite a specific authentication protocol, a specific fraud prevention mechanism, a specific time-based authentication requirement or a specific technological security control comparable to CosmoKey.
Accordingly, CosmoKey does not control the present claim. The claim does not require a specific set of ordered technical steps that improve authentication or network security. Rather, it uses generic computer and network components to automate report review and publication.
Furthermore, publishing a report after a validation flag and reviewer validation is an approval workflow, not a specific improvement to computer or network security. The embedded link is recited as a mechanism for accessing or generating the report, but the claim does not recite the technical security controls allegedly associated with link-based access. The claim does not recite access revocation, token validation upon link selection, link expiration, dynamic permission checking, malware prevention, version control, or any other technical mechanism that would make the embedded link a computer security improvement.
Thus, unlike CosmoKey, the present claim does not recite a specific technological security solution. It recites use of conventional computer components to implement a report validation and publication process. The claim also does not recite the specific technical features necessary to establish the alleged improvement. The claim does not require a particular standardized security schema, permission mapping technique, authentication protocol, authorization exchange, API gateway configuration, security token structure, publication control mechanism, message normalization rule, or data deduplication mechanism. Instead, the claim broadly recites that an integrated delivery platform connects components and exchanges data via API endpoints, with security confirmation by a directory-based identity related services component.
For at least the reasons set forth above, the rejection under 101 is maintained.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an application workflow component”, “an application development component”, “directory-based identity related services component” in claim 1, “a directory-based identity-related services component” in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-10, 12, and 14-19 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.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “responsive to the output data, automatically update at least one file of a plurality of files stored with the output data; generate, based on the output data, at least one report for the at least one updated file; identify a validation flag during generation of a first report of the at least one report; generate, in response to the identified validation flag, a validation request for validation of the generated first report; in response to the received selection, generate the generated first report in the validation request to the report publisher; publish the first report after the first report is validated by the report publisher”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of outputting data and creating a report which is a organizing a human activity and mental processes. That is, the method allows for the generate instructions for a person to follow which is a method fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and concepts performed in the human mind.
This judicial exception is not integrated into a practical application. In particular, the claim recites “an application workflow component to: create and implement one or more workflows; a database storage component to: provide document management and storage of data received from the application workflow component; an application development component to: build application products; a directory-based identity-related services component to: authenticate and authorize computers in a network, and assign and enforce security policies for those computers; an integrated delivery platform to: connect multiple components and exchange component data and Application Programming Interface (API) data with the multiple components via a plurality of API endpoints, the API data including the API endpoints, permissions and authentications, wherein the exchange of component data and API data occurs in response to confirmation of security of component data and API data with the directory-based identity-related services component; a backend server component including: a computer processor; a computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor cause the computer processor to: execute, via the application workflow component, a workflow in connection with an application product of the application development component and output data, wherein the execution of the workflow is via the exchange of API data between the backend server component and the application workflow component; wherein the automatic update is via the exchange of API data between the backend server component, the application workflow component and the database storage component; a communication port to facilitate a transmission of data with remote user devices in support of a graphical user interface display, including a link to the at least one generated report, via a distributed communication network” and “receive a selection of an embedded report link in the validation request”. Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, alone or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are nothing more than mere instructions to apply the exception on a general computer.
Dependent claims 2-3 are also directed to an abstract idea without significantly more because they further narrow the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application or providing significantly more limitations.
Dependent claim 4 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (“receive selection of a selectable key contact link on the graphical user interface display; and generate a communication interface, wherein the communication interface includes a link to the generated report” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment (i.e. generic form of navigating in a computer)) or providing significantly more limitations.
Dependent claim 5 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (“an email or Chat window” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Dependent claim 6 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (“wherein selection of a report link on the graphical user interface display results in the display of a pop-up window with an email icon and a chat icon and the communication interface is generated in response to selection of one of the email icon and the chat icon” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Dependent claim 7 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (“the graphical user display” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Dependent claim 8/9 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application or providing significantly more limitations.
Dependent claim 10 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (“directory- based identity-related services component is further adapted to: authenticate and authorize enterprise users, and assign and enforce security policies for those enterprise users” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “creating one or more workflows; storing data received; responsive to the output data, automatically updating at least one file of a plurality of files stored with the output data; generating at least one report for the updated file; identifying a validation flag during generation of a first report of the at least one report; generating, in response to the identified validation flag, a validation request for validation of the generated first report; in response to the received selection, generating the generated first report in the validation request to the report publisher; and publishing the first report after the first report is validated by the report publisher.”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of outputting data and creating a report which is a organizing a human activity and mental processes. That is, the method allows for the generate instructions for a person to follow which is a method fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and concepts performed in the human mind.
This judicial exception is not integrated into a practical application. In particular, the claim recites “an application workflow component; a database storage component; creating, by an application development component, one or more application products; authenticating and authorizing, via a directory-based identity-related services component, computers in a network; confirming, via an integrated delivery platform, security of Application Programming Interface (API) data with the directory-based identity-related services component, wherein the API data includes API endpoints, permissions and authentications; exchanging, in response to the confirmation and via [[an]] the integrated delivery platform, Application Programming Interface (API) data with multiple connected components; executing, via the application workflow component, the created workflow in connection with the application product and outputting data, wherein execution is via the exchange of API data between a backend server component and the application workflow component; wherein the automatic update is via the exchange of API data between the backend server component, the application workflow component and the database storage component” and “receiving a selection of an embedded report link in the validation request”. Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, alone or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are nothing more than mere instructions to apply the exception on a general computer.
Dependent claim 14 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 12 without successfully integrating the exception into a practical application or providing significantly more limitations.
Dependent claim 15 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 12 without successfully integrating the exception into a practical application (“receiving selection of one of a selectable email icon and a selectable chat icon provided on a graphical user interface display; and generating a communication interface based on the selected icon” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Dependent claim 16 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 12 without successfully integrating the exception into a practical application (“the communication interface is an email message or Chat window” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “creating one or more workflows; storing data received; responsive to the output data, automatically updating at least one file of a plurality of files stored with the output data; generating at least one report for the at least one updated file; identifying a validation flag during generation of a first report of the at least one report; generating, in response to the identified validation flag, a validation request for validation of the generated first report; in response to the received selection, generating the generated first report in the validation request to the report publisher; and publishing the first report after the first report is validated by the report publisher.”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers a method of outputting data and creating a report which is a organizing a human activity and mental processes. That is, the method allows for the generate instructions for a person to follow which is a method fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and concepts performed in the human mind.
This judicial exception is not integrated into a practical application. In particular, the claim recites “an application workflow component; a database storage component; creating, by an application development component, one or more application products; authenticating and authorizing, via a directory-based identity-related services component, computers in a network; confirming, via an integrated delivery platform, security of Application Programming Interface (API) data with the directory-based identity-related services component, wherein the API data includes API endpoints, permissions and authentications; exchanging, in response to the confirmation and via the integrated delivery platform, Application Programming Interface (API) data with multiple connected components, the API data including one or more API endpoints; executing, via the application workflow component, the created workflow in connection with the application product and outputting data, wherein execution is via the exchange of API data between a backend server component and the application workflow component; wherein the automatic update is via the exchange of API data between the backend server component, the application workflow component and the database storage component” and “receiving a selection of an embedded report link in the validation request”. Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, alone or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are nothing more than mere instructions to apply the exception on a general computer.
Dependent claim 18 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 17 without successfully integrating the exception into a practical application or providing significantly more limitations.
Dependent claim 19 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 17 without successfully integrating the exception into a practical application (“receiving selection of a selectable key contact link on a graphical user interface display; and generating a communication interface, wherein the communication interface includes a link to the generated report” is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment (i.e. generic form of navigating in a computer)) or providing significantly more limitations.
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.
The factual inquiries 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.
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.
Claim(s) 1, 10, 12 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650) and Takatsu (US 20110202502).
As per claim 1/12/17, Davis discloses a system comprising:
an application workflow component to: create and implement one or more workflows (fig. 6-8, abstract, “A business intelligence, application development, and application connectivity component may implement business workflow products and exchange application authentication data with the directory-based identity-related services component…At S206, a business intelligence, application development, and application connectivity component may implement business workflow products (e.g., an inventory flow, a membership flow, etc.).”;
a database storage component to: provide document management and storage of data received from the application workflow component (paragraph 6, “A database storage component may provide document management and storage of dashboard tables and lists associated with inventory data receive from the business intelligence, application development, and application connectivity component. “[0026] A collaborative platform component 130 may provide document management and storage of dashboard list and Application Programming Interface (“API”) data. According to some embodiments, storage may be achieved via a Structured Query Language (“SQL”) element, an ORACLE® database, a DATAVERSE® storage solution, etc. A cloud-based storage and data management engine 140 may exchange secure authentication storage data with the business intelligence, application development, and application connectivity component 120.”);
an application development component to: build application products (“[0037] The system 400 may further include MICROSOFT™ POWER AUTOMATE® 420 to implement business workflow products and provide application authentication information to the AZURE® Active Directory 410. According to some embodiments, POWER AUTOMATE® 420 is associated with the MICROSOFT™ Power Platform business intelligence, application development, and application connectivity software applications. In particular, POWER AUTOMATE® 420 may comprise a toolkit for implementing business workflow products such as a SHAREPOINT® site inventory flow 422 and/or a SHAREPOINT® site membership flow 424.”);
a directory-based identity-related services component to: authenticate and authorize computers in a network, and assign and enforce security policies for those computers (“[0036] FIG. 4 is a particular example of an enterprise governance inventory and automation tool or system 400 according to some embodiments. The system 400 includes a MICROSOFT™ AZURE® Active Directory 410 that may authenticate and authorize enterprise users and computers in a network. In general, “Active Directory” is a set of processes and services that provides a range of directory-based identity-related services. An Active Directory may authenticate and authorize users and computers in a network, assign and enforce security policies, install or update software, etc. For example, when a user logs into a computer, the Active Directory may check the submitted username and password and determine whether a user is a system administrator or a “normal” user”)”);
an integrated delivery platform to: connect multiple components and exchange component data and Application Programming Interface (API) data with the multiple components via a plurality of API endpoints, the API data including the API endpoints, permissions and authentications, wherein the exchange of component data and API data occurs in response to confirmation of security of component data and API data with the directory-based identity-related services component (“[0033] At S208, the business intelligence, application development, and application connectivity component may exchange authentication data with the directory-based identity-related services component. At S210, a collaborative platform component may provide document management and storage of dashboard list data (e.g., via an SQL or ORACLE® database, a DATAVERSE® storage solution, etc.). At S212, the collaborative platform component may exchange data with the business intelligence, application development, and application connectivity component along with API data. At S214, a cloud-based storage and data management engine may exchange secure authentication storage data with the business intelligence, application development, and application connectivity component. “, [0071] The configuration of a system or tool in accordance with embodiments described herein may be presented on a Graphical User Interface (“GUI”). For example, FIG. 11 is a collaboration system display 1100 including graphical representations 1110 of elements of an enterprise governance inventory and automation tool. Moreover, selection of an element, such as a collaborative platform component or API developer platform (e.g., via touchscreen or computer mouse pointer 1190) may display configuration information about that element and/or let an operator or administrator adjust the configuration (e.g., to modify inventory information). The display 1100 may further let the operator or administrator select a “Save” icon 1150 to cause the system or platform to save changes, apply reconfigurations, etc.”);
a backend server component including: a computer processor; a computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor cause the computer processor to (“[0072] The embodiments described herein may be implemented using any number of different hardware configurations. For example, FIG. 12 illustrates an apparatus 1200 that may be, for example, associated with the systems and architectures 100, 400, 900 described with respect to FIGS. 1, 4, and 9, respectively. The apparatus 1200 comprises a processor 1210, such as one or more commercially available Central Processing Units (“CPUs”) in the form of one-chip microprocessors, coupled to a communication device 1220 configured to communicate via a communication network (not shown in FIG. 12). The communication device 1220 may be used to communicate, for example, with one or more remote cloud-based environments, administrator computers, and/or communication devices (e.g., PCs and smartphones). Note that communications exchanged via the communication device 1220 may utilize security features, such as those between a public internet user and an internal network of an insurance company and/or an enterprise. The security features might be associated with, for example, web servers, firewalls, and/or PCI infrastructure. The apparatus 1200 further includes an input device 1240 (e.g., a mouse and/or keyboard to enter information about data sources, mappings, third-parties, etc.) and an output device 1250 (e.g., to output reports regarding inventory, recommended changes, alerts, etc.).”):
execute, via the application workflow component, a workflow in connection with an application product of the application development component and output data, wherein the execution of the workflow is via the exchange of API data between the backend server component and the application workflow component (fig. 2, [0037] The system 400 may further include MICROSOFT™ POWER AUTOMATE® 420 to implement business workflow products and provide application authentication information to the AZURE® Active Directory 410. According to some embodiments, POWER AUTOMATE® 420 is associated with the MICROSOFT™ Power Platform business intelligence, application development, and application connectivity software applications. In particular, POWER AUTOMATE® 420 may comprise a toolkit for implementing business workflow products such as a SHAREPOINT® site inventory flow 422 and/or a SHAREPOINT® site membership flow 424., [0033] … At S212, the collaborative platform component may exchange data with the business intelligence, application development, and application connectivity component along with API data. At S214, a cloud-based storage and data management engine may exchange secure authentication storage data with the business intelligence, application development, and application connectivity component.”, “[0064] FIGS. 6 through 8 are business flow automation displays according to some embodiments. As shown 600 in FIG. 6, the system may manually trigger a flow 610 and then determine HTTP information 620 (e.g., method, URI, headers, queries, etc.). As shown 700 in FIG. 7, the system may then parse JavaScript Object Notation (“JSON”) 710 information (e.g., to determine content and schema and let an operator generate from sample 712) and apply to each 720. As shown 800 in FIG. 8, system may then let a user create an item 810 (e.g., site address, list name, title, site identifier, URL, etc.).”, paragraphs 59-64);
responsive to the output data, automatically update, via the integrated delivery platform, at least one file of a plurality of files stored in the database storage component with the output data, wherein the automatic update is via the exchange of API data between the backend server component, the application workflow component and the database storage component (“[0030] The system 100 may store information into and/or retrieve information from the collaborative platform component 130. The collaborative platform component 130 might be locally stored or reside remote from other elements of the system 100. As will be described further below, the collaborative platform component 130 may be used by the system 100 in connection with an interactive user interface to access and update electronic records “, “[0033] At S208, the business intelligence, application development, and application connectivity component may exchange authentication data with the directory-based identity-related services component. At S210, a collaborative platform component may provide document management and storage of dashboard list data (e.g., via an SQL or ORACLE® database, a DATAVERSE® storage solution, etc.). At S212, the collaborative platform component may exchange data with the business intelligence, application development, and application connectivity component along with API data. At S214, a cloud-based storage and data management engine may exchange secure authentication storage data with the business intelligence, application development, and application connectivity component.”, “For example, FIG. 3 illustrates a graphical user display 300 with an inventory dashboard list 310 according to some embodiments. The inventory dashboard list 310 might include, for example, a site title, a site URL, site administrators, a member count, a site identifier, etc. Selection of a portion of the display (e.g., via a touchscreen or computer mouse pointer 390) may provide more detailed information about that element (e.g., contact information for site administrators). Moreover, selection of an “Update” icon 350 may be used to adjust information in the list 310 (e.g., by deleting a site), selection of a “Filter” 360 may sort or otherwise adjust the list 310 (e.g., by only showing sites with more than 1,000 members), and selection of an “Export” icon 370 may save the list 310 information. Note that the embodiment disclosed in FIG. 3 is provided only as an example and other embodiments may incorporate other types of inventory information (e.g., for YAMMER® or TEAMS® inventory lists), automated applications (e.g., associated with a re-certification process), etc.”, ”[0070] At S1008, the POWER AUTOMATE® component may exchange AZURE® authentication data with the AZURE® Active Directory component. At S1010, a database storage component may provide document management and storage of dashboard tables and lists. At S1012, the database storage component may receive inventory data from the POWER AUTOMATE® component. At S1014, a DATAVERSE® engine may exchange DATAVERSE® secure authentication storage data with the POWER AUTOMATE® component. At S1016, a computer processor of at least one governance or user application may automatically retrieve information from the database storage component in support of a graphical user display (e.g., showing YAMMER® or TEAMS® inventory data) via a distributed communication network.”, ;
generate, based on the output data, at least one report for the at least one updated file; publish the at least one report (“[0026] A collaborative platform component 130 may provide document management and storage of dashboard list and Application Programming Interface (“API”) data. According to some embodiments, storage may be achieved via a Structured Query Language (“SQL”) element, an ORACLE® database, a DATAVERSE® storage solution, etc. A cloud-based storage and data management engine 140 may exchange secure authentication storage data with the business intelligence, application development, and application connectivity component 120. Moreover, a computer processor of at least one governance or user application 150 may automatically determine enterprise site inventory information. Responsive to the determined enterprise site inventory information, the governance or user application 150 may then automatically determine enterprise site membership information. The governance or user application 150 can then transmit the dashboard list data to the collaborative platform component 130 via a communication port in support of a graphical user display (including the enterprise site inventory and membership information) via a distributed communication network.”,“[0035] At S220, the system may transmit the dashboard list data to the collaborative platform component via a communication port in support of a graphical user display (including the enterprise site inventory and membership information) via a distributed communication network. For example, FIG. 3 illustrates a graphical user display 300 with an inventory dashboard list 310 according to some embodiments. The inventory dashboard list 310 might include, for example, a site title, a site URL, site administrators, a member count, a site identifier, etc.”, “[0027] The system 100 may therefore access information in the collaborative platform component 130 (e.g., storing a set of electronic records associated with a set of enterprise sites, each record including, for example, one or more record identifiers, membership information, site owners, etc.). The system 100 may also store information into other data stores and utilize a runtime environment to view, analyze, and/or update the electronic records. The system 100 may also exchange information with a cloud-based environment (e.g., via a firewall) executing a family of client software, server software, and services. According to some embodiments, an interactive graphical user interface platform of the system 100 (and, in some cases, enterprise data and/or third-party data) may facilitate forecasts, decisions, predictions, and/or the display of communications via one or more remote administrator computers (e.g., to identify appropriate updates to inventory rules and logic). Note that the system 100 and/or any of the other devices and methods described herein might be associated with a third party, such as a vendor that performs a service for an enterprise.”);
publish the at least one report (“[0026]… The governance or user application 150 can then transmit the dashboard list data to the collaborative platform component 130 via a communication port in support of a graphical user display (including the enterprise site inventory and membership information) via a distributed communication network. According to some embodiments, system 100 also includes an API developer platform 160 to: connect multiple services and devices, and exchange API data with the business intelligence, application development, and application connectivity component 120.”, “[0035] At S220, the system may transmit the dashboard list data to the collaborative platform component via a communication port in support of a graphical user display (including the enterprise site inventory and membership information) via a distributed communication network. For example, FIG. 3 illustrates a graphical user display 300 with an inventory dashboard list 310 according to some embodiments. The inventory dashboard list 310 might include, for example, a site title, a site URL, site administrators, a member count, a site identifier, etc. Selection of a portion of the display (e.g., via a touchscreen or computer mouse pointer 390) may provide more detailed information about that element (e.g., contact information for site administrators).”);
a communication port to facilitate a transmission of data with remote user devices in support of a graphical user interface display, via a distributed communication network (“[0035] At S220, the system may transmit the dashboard list data to the collaborative platform component via a communication port in support of a graphical user display (including the enterprise site inventory and membership information) via a distributed communication network. For example, FIG. 3 illustrates a graphical user display 300 with an inventory dashboard list 310 according to some embodiments. The inventory dashboard list 310 might include, for example, a site title, a site URL, site administrators, a member count, a site identifier, etc. Moreover, selection of an “Update” icon 350 may be used to adjust information in the list 310 (e.g., by deleting a site), selection of a “Filter” 360 may sort or otherwise adjust the list 310 (e.g., by only showing sites with more than 1,000 members), and selection of an “Export” icon 370 may save the list 310 information. Note that the embodiment disclosed in FIG. 3 is provided only as an example and other embodiments may incorporate other types of inventory information (e.g., for YAMMER® or TEAMS® inventory lists), automated applications (e.g., associated with a re-certification process), etc.”.)
However, Davies does not disclose but Gauthier discloses in response to the received selection, generate the generated first report in the validation request to the report publisher (“[0050]… In step 904, the client module receives a URL which points to result files produced by running the analytic. In step 905, the module obtains the results, for example, by requesting a web page with links to the data or by requesting the data itself. In step 906, the client module renders the result report (for example, a web page), resolving any references to "real" data as needed, performing other processing if needed, and ends….[0055]… In one embodiment, the reporting server returns a list of URLs. In step 1306 the client module obtains the results, for example by performing an HTTP "Get" operation to retrieve the report components using one or more URLs obtained in step 1305, which returns links to the report components/data or the report components themselves. These components may be stored, for example, in a results data repository managed by a CMS. In step 1307, the client module renders the resulting report components, resolving any links if present, performs other processing as needed, and ends.” Gauthier teaches retrieving and rendering report components in response to use of a report URL. It states that the client receives a URL which points to the result files produced by running the analytics” obtains results by requesting a web page with links to the data, and “renders the resulting report components”. Takatsu below teaches that the reviewer follows the document link to brose the workflow document and returns a review result. When Gauthier’s generated report is used as the workflow document in the Takatsu review/approval workflow, the report is generated to the reviewing report publisher in response to selection of the embedded report link);
publish the first report after the first report is validated by the report publisher ([0051] Once a report has been generated by a user, the user may wish to "publish" the report so that other consumers can use it as well. A report is in one sense a particular instance or running a report template with one or more designated analytics and associated parameter values. FIG. 10 is an example flow diagram illustrating an example process for publishing a report using an example Analytics Server Computing System. Steps 1001-1004 are similar to steps 901-904 in FIG. 9. In step 1005, the client module communicates with the reporting service/CMS to publish the (executed) report. It passes to the reporting service the URL returned from running the report, and keeps an identifier reference to the published report. In step 1006, the client module retrieves a report document using the identifier reference and displays the retrieved report, and ends. Other processing steps after publishing a report can be similarly envisioned and implemented.);
publishing a report including a link to the at least one generated report ([0050]…his communication results in a call to an analytic web service, which in turn calls an engine to perform the analytic. In step 904, the client module receives a URL which points to result files produced by running the analytic. In step 905, the module obtains the results, for example, by requesting a web page with links to the data or by requesting the data itself. In step 906, the client module renders the result report (for example, a web page), resolving any references to "real" data as needed, performing other processing if needed, and ends.)”,” 0051] Once a report has been generated by a user, the user may wish to "publish" the report so that other consumers can use it as well. A report is in one sense a particular instance or running a report template with one or more designated analytics and associated parameter values. FIG. 10 is an example flow diagram illustrating an example process for publishing a report using an example Analytics Server Computing System. Steps 1001-1004 are similar to steps 901-904 in FIG. 9. In step 1005, the client module communicates with the reporting service/CMS to publish the (executed) report. It passes to the reporting service the URL returned from running the report, and keeps an identifier reference to the published report. In step 1006, the client module retrieves a report document using the identifier reference and displays the retrieved report, and ends. Other processing steps after publishing a report can be similarly envisioned and implemented.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Gauthier in the teaching of Davies, 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.
However, Davies in view of Gauthier does not disclose but Takatsu discloses identify a validation flag during generation of a first report of the at least one report ([0052] FIG. 3 shows an example of the metadata DB 18. Each record in the metadata DB 18 includes an ID for identifying the record, a document ID for identifying the corresponding workflow document, and one or more tags attached to the workflow document. A tag is a part of metadata. Metadata include information on a workflow document such as a document URL and tags. [0053] Examples of tags relating to a workflow include: tags indicating types of tasks or documents, e.g. "Invention_Report", "Technical_Report", and "Request_For_Decision"; tags indicating organizational units, e.g. "XYZ_Laboratory" and "ABC_Department"; tags indicating informal groups, e.g. "XXX_Subcommittee" and "YYY_StudyGroup"; and tags indicating statuses, e.g. "In_Preparation", "In_Preparation:name", "Requesting_Review", "Approved:name", "Rejected", "To:name", "CC:name", and "To:archive". The exemplary workflow system may be configured such that tags indicating organizational units cannot be attached to a workflow document unless the users are authenticated.
[0054] Tags indicating the statuses of workflows and workflow documents are preferably protected from being altered without authorization or by mistake. Therefore, in this embodiment, tags indicating the statuses of workflows and workflow documents are treated as system tags that are automatically generated and altered by the exemplary workflow system and cannot be altered by the users. Examples of system tags include "Creator:name", "Creator:name(2006-08-31/23:59:59)", "Altered:name", "Altered:name(2006-08-31/23:59:59)", "To:name", "CC:name", "Requesting_Review", "Reviewed:name", "Reviewed:name(2006-08-31/23:59:59)", "Requesting_Approval", "Approved:name", "Approved:name(2006-08-31/23:59:59)", "Rejected", "Rejected:name", and "Rejected:name(2006-08-31/23:59:59)".);
generate, in response to the identified validation flag, a validation request for validation of the generated first report ([0066] As shown in FIG. 9, the creator attaches one or more tags to a workflow document and requests the metadata management unit 1 to register the workflow document (step S11). The metadata management unit 1 causes the authentication unit 4 to authenticate the creator (step S12) and causes the workflow determining unit 2 to determine a workflow for the workflow document (step S13). Then, the creator uploads the workflow document to the document registration unit 3 (step S14). [0067] Meanwhile, when receiving an RSS feed from the metadata management unit 1, each of users A, B, and C (workflow participants) reviews and/or approves the workflow document registered in the document registration unit 3, and returns the result to the metadata management unit 1 (steps S15 and S16). When each of the users A, B, and C accesses the document registration unit 3, the authentication unit 4 authenticates each of the users A, B, and C (step S17).);
receive a selection of an embedded report link in the validation request ([0061] The workflow system determines a workflow based on the tags attached by the creator (step S3) and attaches a participant tag indicating the first workflow participant and a status tag indicating a workflow status to the workflow document after confirmation by the creator (step S4). [0062] Then, the workflow system delivers the metadata (including a title, a description, a URL, etc.) of the workflow document as an RSS feed to the first workflow participant (step S5). [0063] When receiving the RSS feed, the first workflow participant reviews and/or approves the workflow document (step S6). Then, the workflow system updates the status tag based on the result of the review and/or approval, and updates the participant tag to indicate the next workflow participant if there is one (step S7). If there is another workflow participant, the workflow system repeats steps S5 through S7.);
approving/reviewing before workflow completion and status updating based on the approval result and updating the status tag based on the result of the review and/or approval ([0100] When receiving the request, the tag analysis unit 15 refers to the tag definition DB 19 (steps S175) and requests the metadata managing unit 12 to update the metadata of the reviewed workflow document (step S176). Then, the metadata managing unit 12 updates the metadata in the metadata DB 18 (step S177). Take, for example, a case where the tags of the workflow document shown in FIG. 20 are "Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Requesting_Review To:Suzuki" before the review. If the reviewer accepts the workflow document, the tags are updated to "Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Reviewed:Suzuki To:Sato". If the reviewer rejects the workflow document, the tags are updated to "Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Rejected: Suzuki To:Yamada").
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Takatsu in the teaching of Davies in view of Gauthier, in order to update the status tag and the participant tag after the review and/or approval (Takatsu paragraph 16).
As per claim 10, Davies discloses wherein the directory-based identity-related services component is further adapted to: authenticate and authorize enterprise users and computers in a network, and assign and enforce security policies for those enterprise users (“[0006] A system may include a directory-based identity-related services component that authenticates and authorizes enterprise users and computers in a network and enforces security policies.”).
Claim(s) 2-3, 14 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650), Takatsu (US 20110202502), as disclosed in the rejection of claim 1, in further view of Marshall (US 20080065396).
As per claim 2/14/18, Davies discloses generating at least one report for the updated file (paragraph 26). However, Davies does not explicitly disclose but Marshall discloses generate at least two reports for the updated file, wherein the at least two reports have a different report type ([0374] At 2626, reports may be generated based upon the data recorded by the employee. The systems and methods of the present invention are designed to automatically generate desired reports with little or no input from a user. Numerous reports may be generated in a variety of formats including, but not limited to, activity summary reports, tip declaration problem reports, and IRS reports such as TRAC statements, IRS Form 8027, and IRS Publication 1244 reports including IRS forms 4070A and 4070. In some embodiments of the present invention capable of generating IRS forms 4070A and 4070, such reports may be automatically created and stored by the employee such that the employee maintains compliance with the IRS' recordkeeping requirements. Additionally, such reports are likely to be required if the employee is ever audited. In embodiments of the present invention in which tip declaration problem reports are created, such reports allow the employee to increase his or her declared tips via notification of his or her employer in an effort to avoid an IRS audit.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Marshall, which solves the same problem of report generation, in the teaching of Davies, 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.
As per claim 3, Davies in view of Gauthier, Takatsu and Marshall disclose all the limitation of claim 2. Davies does not explicitly disclose but Marshall explicitly discloses receive selection of a report type; and display the report in a selected report type format (paragraph 154-155, “[0155] At 626, the user is prompted to select a report type. In the exemplary GrataSoft embodiment, such reports include, but are not limited to, activity summary report 628a, IRS TRAC statement report 628b, IRS Form 8027 report 628c, tip declaration problem report 628d, IRS form 4070A report 628e, IRS form 4070 report 628f, and staff training history report 628g.”)(please see claim 2 rejection for combination rationale).
Claim(s) 4-5, 15-16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650) and Takatsu (US 20110202502), as disclosed in the rejection of claim 1/17, in view of Koch (US 8146004).
As per claim 4/19, Davies does not disclose but Koch discloses receive selection of a selectable key contact link on the graphical user interface display; and generate a communication interface, wherein the communication interface includes a link to the generated report (col. 3:20-28, “In response to the processing mechanism detecting a manipulation of the user interface device wherein a first graphical indicia from the first set of graphical indicia and a second graphical indicia from the second set of graphical indicia are made to at least partially overlap, the processing mechanism generates an electronic message for sending to a contact associated with the first graphical indicia wherein the electronic message includes a file associated with the second graphical indicia.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Koch, which solves the same problem of sharing files, in the teaching of Davies, 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.
As per claim 5, Davies in view of Gauthier, Takatsu and Koch disclose all the limitation of claim 4. Davies does not disclose but Koch further discloses wherein the communication interface is an email message or a chat window (col. 4:41-53, “12) The electronic messaging client 103 is operatively coupled to the graphical user interface 107. The electronic messaging client 103 is illustratively implemented using an email program such as Microsoft Outlook.TM., Lotus Notes.TM., a web mail application, an instant messaging application, a file transmission protocol, an internet protocol television (IPTV) messaging application, or any of various combinations thereof. The graphical user interface 107 may, but need not, be provided as part of the operating system 104. The operating system 104 may be implemented, for example, using Microsoft Windows.TM., MacIntosh OS.TM., Linux.TM., or any of a number of other operating systems.”)(please see claim 4 rejection for combination rationale).
As per claim 15, Davies does not disclose but Koch discloses receiving selection of one of a selectable email icon and a selectable chat icon provided on a graphical user interface display; and generating a communication interface based on the selected icon (col. 3:20-28, “In response to the processing mechanism detecting a manipulation of the user interface device wherein a first graphical indicia from the first set of graphical indicia and a second graphical indicia from the second set of graphical indicia are made to at least partially overlap, the processing mechanism generates an electronic message for sending to a contact associated with the first graphical indicia wherein the electronic message includes a file associated with the second graphical indicia.”)(please see claim 4 rejection for combination rationale)
As per claim 16, Davies in view of Gauthier, Takatsu and Koch discloses all the limitations of claim 15. Davies does not disclose but Koch discloses receiving selection of one of a selectable email icon and a selectable chat icon provided on a graphical user interface display; and generating a communication interface based on the selected icon (col. 4:41-53, “12) The electronic messaging client 103 is operatively coupled to the graphical user interface 107. The electronic messaging client 103 is illustratively implemented using an email program such as Microsoft Outlook.TM., Lotus Notes.TM., a web mail application, an instant messaging application, a file transmission protocol, an internet protocol television (IPTV) messaging application, or any of various combinations thereof. The graphical user interface 107 may, but need not, be provided as part of the operating system 104. The operating system 104 may be implemented, for example, using Microsoft Windows.TM., MacIntosh OS.TM., Linux.TM., or any of a number of other operating systems.”)(please see claim 4 rejection for combination rationale).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650), Takatsu (US 20110202502), as disclosed in the rejection of claim 1/12, in view of Downling (US 20190361580).
As per claim 6, Davies does not disclose but Downling discloses wherein selection of a report link on the graphical user interface display results in the display of a pop-up window with an email icon and a chat icon and the communication interface is generated in response to selection of one of the email icon and the chat icon (paragraph 25, “[0025] The one or more selectable user interface elements for initiating an electronic communication between the first, viewing, user and the concurrent user, may include a selectable element for initiating real-time text, voice, and/or audio communications between the first user and the concurrent user, a selectable element for initiating an email communication between the first user and the concurrent user, and/or a selectable element for initiating a real-time group communication between the first user and each other concurrent user in the shared document. According to some examples, upon selecting one of the selectable user interface elements for initiating electronic communications, a messaging window may be caused to be displayed in in the viewing/selecting user's shared document user interface, with the corresponding concurrent user's contact information pre-populated in the “to” field of the messaging window. In additional examples, upon selecting one of the selectable user interface elements for initiating electronic communications, a messaging application separate from the shared document may be automatically opened and the “to” field of a messaging window associated with that application may be automatically populated with the corresponding concurrent user's contact information (e.g., the user's phone number, the user's email address, the user's instant messaging alias).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the current invention to include the limitation above as taught by Downling, which solves the same problem of sharing files, in the teaching of Davies, 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(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650), Takatsu (US 20110202502), as disclosed in the rejection of claim 1, in view of Carriero (US 10341275).
As per claim 7, Davies does not disclose but Carriero discloses wherein the published report displays a publisher comment on the graphical user display (abstract, “For example, users can share a web link to a collection of content items, such as documents, spreadsheets, photos, and any other media, with other users stored in an online content management system. The commenting system can provide a comment interface displayable alongside a respective content item and the comments can be saved for each user and the content item with associated comments can be synced across the multiple users.”, col. 1:45-60).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Carriero in the teaching of Davies, in order to provide a commenting system for multiple users to provide and share comments to shared documents (abstract, Carriero).
Claim(s) 8-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis (US 2023/0328049) in view of Gauthier (US 2007/0244650) and Takatsu (US 20110202502), as disclosed in the rejection of claim 1, in view of Crittenden (US 7636902).
As per claim 8, Davies does not disclose but Crittenden discloses wherein the generated at least one report is validated prior to publication (col. 3:27-30, “(14) The report manager 102 can interact with a report checker 112 automatically to send a request to validate report 114 to the report checker 112 whenever the report manager 102 generates the report 106.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the filing of the invention to include the limitation above as taught by Crittenden in the teaching of Davies, in order to determine any errors in the report (Crittenden, col. 6:19).
As per claim 9, Davies in view of Gauthier, Takatsu and Crittenden disclose all the limitation of claim 8. Davies does not disclose but Crittenden discloses wherein a publisher receives a validation request in response to generation of the report (4:27-39, “(14) The report manager 102 can interact with a report checker 112 automatically to send a request to validate report 114 to the report checker 112 whenever the report manager 102 generates the report 106. Alternatively, a user can enter input via the user interface 110 to send the request to validate report 114 to the report checker 112. As yet another alternative, a user can interact directly with the report manager 102 to have it send the request to validate report 114 to the report checker 112. The report manager 102 can send the report 106 requiring validation to the report checker 112 when the request to validate report 114 is sent to the report checker 112, or the user can retrieve and forward the report 106 via the user interface 110.”)(please see claim 8 rejection for combination rationale).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OMAR ZEROUAL whose telephone number is (571)272-7255. The examiner can normally be reached Flex schedule.
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, Kevin Flynn can be reached at 5712703108. 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.
OMAR . ZEROUAL
Examiner
Art Unit 3628
/OMAR ZEROUAL/Primary Examiner, Art Unit 3629
Prosecution Insights