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 .
DETAILED ACTION
This action is in response to papers filed on 1/2/2026.
Claims 1, 2, 5, 8, 12-14, and 16 have been amended.
No claims have been cancelled.
No claims have been added.
Claims 1-20 are pending.
Claim Objections
Claim 14 is objected to because of the following informalities: The language of Claim 14, such as the phrase “further base said facilitate delivery of” may be confusing. Although this does not necessitate a 35 USC § 112 claim rejection, Examiner suggests amending the language for clarity. Some non-limiting suggestions include “further base said facilitating of the delivery of” or “further base the facilitating of delivery of”. Appropriate correction is advised.
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 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
The claims are directed to a process (method as introduced in Claim 1) and/or system (Claim 13), thus Claims 1-20 fall within one of the four statutory categories. See MPEP 2106.03.
Step 2A, Prong 1:
The claimed invention recites an abstract idea according to MPEP §2106.04. The independent claims which recite the following claim limitations as an abstract idea, are underlined below.
Claims 1 and 13 recite (as represented by the language of Claim 1):
storing in memory at least metadata of a digital model1 of a system, wherein the digital model includes a plurality of discrete subsystems representing different functions of the system, each subsystem including a plurality of discrete model elements, and design responsibility for different ones of the model elements is assigned to different ones of a plurality of engineering teams;
receiving, from each of a first user and a second user that are not part of a first engineering team of the plurality of engineering teams, respective requests to access a particular model element of a particular subsystem, wherein design responsibility for the particular model element is assigned to the first engineering team, and the particular model element includes at least one redaction implemented according to a security policy of the first engineering team; and
based on the request from the first user lacking a redaction token2 corresponding to the at least one redaction, facilitating delivery of a redacted version of the particular model element to the first user that includes the at least one redaction; and
based on the request from the first user including the redaction token, facilitating delivery of an unredacted version of the particular model element to the second user;
1 “Model” does not represent any type of artificial intelligence, machine learning, or related concepts, but refers to a designing and planning tool.
2 “Token” merely refers to a security policy method and could represent non-computer methods of supplying authorization, credentials, or other types of permissions.
The underlined claim limitations as emphasized above, as drafted, recite a process that, under its broadest reasonable interpretation covers the performance of commercial or legal interactions in the form of contracts or legal agreements or requirements between collaborative groups. Other than reciting a computer implementation, nothing in the claim elements precludes the step from encompassing the performance of commercial or legal interactions which represents the abstract idea of certain methods of organizing human activity. But for the recitation of generic implementation of computer system components, the claimed invention merely recites a process for providing access to different entities based on that entities security permissions. For example, see specification at [0070], which provides examples of contracts or legal agreements or requirements between the collaborative groups which would require permissions. Examples include, intellectual property requirements, trade secret agreements, non-disclosure agreements, license requirements, export controls ("ITAR" regulations), etc.
Step 2A, Prong 2:
This judicial exception is not integrated into a practical application. In particular, the claims recite additional elements such as:
a system for sharing a digital model, comprising: a security server comprising processing circuitry operatively connected to memory and configured to (including a security server used for receiving and facilitating delivery steps as recited in Claim 13); and
storing [data] in memory.
In particular, the additional elements cited above beyond the abstract idea are recited at a high-level of generality and simply equivalent to a generic recitation and basic functionality that amount to no more than mere instructions to apply the judicial exception using generic computer technology components.
Accordingly, since the specification describes the additional elements in general terms, without describing the particulars, the additional elements may be broadly but reasonably construed as generic computing components being used to perform the judicial exception (see specification at [0015]-[0018], descriptions of computer components performing generic functions, such as transmitting, receiving, and processing data3; [0031]-[0033]; [0058]-[0068], additional generic descriptions of the security server4). These claimed additional elements merely recite the words “apply it" (or an equivalent) with the judicial exception, or merely include instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f).
Additionally, reciting a “digital” model merely attempts to tie the claimed invention to a particular technological environment. However, this is also recited at a high level of generality and simply reciting that the model is digital (and/or applying it to that particular environment) does not provide any material to render the claims significantly more than the abstract ideas. The steps and functions of the claims would be the same regardless of whether or not the model is digital or non-digital, and therefore, the claimed invention is not necessarily rooted in the recited digital environment.
Thus, the additional claim elements are not indicative of integration into a practical application, because the claims do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e)). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea and the claims are directed to an abstract idea.
3 It is also noted that the specification (including the drawings and schematics) provides little, if any, descriptions of the computer components themselves (server, security server, processing circuitry, and memory), such as how they are implemented or any technical details.
4 Although these sections describe the activities of the claimed invention being performed by the security server, the security server used is recited at a high level of generality. There is no material that clearly indicates how the security server would be used to perform these activities in a significant manner beyond a generic server performing expected functions and/or how the security server would represent a specialized machine used for performing these activities.
Step 2B:
The claims do not include additional elements, individually 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 element amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept at Step 2B. Thus, the claim is not patent eligible.
Dependent Claims:
Claims 2-12 and 14-20 recite further elements related to the access and permission steps of the parent claims. These activities fail to differentiate the claims from the related activities in the parent claims and fail to provide any material to render the claimed invention to be significantly more than the identified abstract ideas, as outlined below.
Claim 2 recites “utilizing a token validation algorithm to determine whether the redaction token is valid or invalid; and said facilitating delivery of the unredacted version of the particular model element is further based on the token validation algorithm indicating that the redaction token is valid”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract. It is also noted that the algorithm is recited generically and there is no detail regarding the algorithm or how it is implemented.
Claims 3 and 15 recites “receiving, from an administrative user associated with the first engineering team, an indication of a plurality of discrete digital redactions that correspond to different model elements of the particular subsystem; and associating different redaction tokens with each of the discrete redactions”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract.
Claim 4 recite “wherein said utilizing the token validation algorithm comprises: comparing the received redaction token, or a value derived from the received redaction token, with a master redaction token corresponding to the at least one redaction, or a value derived from the master redaction token; and determining whether the received redaction token is validated based on the comparison”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract. It is also noted that the algorithm is recited generically and merely describes the comparison of the token to master token to determine validity with little detail.
Claims 5 and 16 recite “receiving a request from the first or the second user to access an additional model element of the particular subsystem that is non-redacted; and facilitating delivery of the additional model element without requiring receipt of a redaction token”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract.
Claim 6 recites “each engineering team has one or more first security requirements that must be fulfilled to access its model elements; and said facilitating steps are further based on the request from the user fulfilling the one or more security requirements of the first engineering team”, which specifies further steps related to rules for determining users’ access to model elements, but does not make the claims any less abstract.
Claims 7 and 17 recite “the one or more security requirements of the first engineering team include one or more first security requirements and one or more second security requirements that differ from the one or more first security requirements; compliance of the request with the one or more first security requirements of the first engineering team is a prerequisite for delivery of the redacted version and the unredacted version of the particular model element; and compliance of the request with the one or more second security requirements of the first engineering team is a prerequisite for delivery of the unredacted version, but not the redacted version, of the particular model element”, which specifies further steps related to rules for determining users’ access to model elements, but does not make the claims any less abstract. The server in Claim 17 is recited at a high level of generality and merely adding that a server is used to perform the steps does not integrate the abstract idea into a practical application or provide an inventive concept. The “security client” is recited at a high level of generality and merely reciting the security client to perform these steps does not integrate the abstract idea into a practical application or provide an inventive concept.
Claim 8 recites “the security server performs said storing step; and the method includes the security server validating the redaction token, and based on a successful validation, sending an indication of the request to a security client of the first engineering team to facilitate determination, by the security client, of whether the request fulfills the one or more second security requirements”, which further specifies a security server used to perform steps of the parent claims, but does not lead toward eligibility. The server is recited at a high level of generality and merely adding that a server is used to perform the steps does not integrate the abstract idea into a practical application or provide an inventive concept. The “security client” is recited at a high level of generality and merely reciting the security client to perform these steps does not integrate the abstract idea into a practical application or provide an inventive concept. See specification at [0039]. The security client is described generically with little technical detail.
Claims 9 recites “wherein the one or more security requirements include at least one of: a requirement that an IP address of a computing device that the request received from is not a blacklisted IP address; a requirement that the computing device is not located in an unauthorized geographic territory; and a requirement that a static device identifier of the computing device is not blacklisted”. Claim 10 recites “wherein the one or more security requirements include at least one of: a requirement that the user is not part of a user group that the first engineering team has prohibited from accessing unredacted model elements of the first engineering team; and a requirement that the redaction token has not been used more than a predefined number of permitted times”. Claim 11 recites “rejecting a request for an unredacted version of the particular model element based on the particular model element being flagged for inclusion in a patent application that has not yet been filed”. Claim 19 recites a combination of elements from Claims 9-11. These claims specify further steps related to rules for determining users’ access to model elements, but do not make the claims any less abstract.
Claim 12 recites “a security server performs said storing step, receiving step, and at least one of the facilitating delivery steps; said facilitating delivery of the redacted version of the particular model element comprises the security server obtaining the redacted version from its own storage, and sending the redacted version to the user; and said facilitating delivery of the unredacted version of the particular model element to the user comprises the security server obtaining the unredacted version from the first engineering team in response to the request, and sending the unredacted version to the user after it is received from the first engineering team”, which further specifies a security server used to perform steps of the parent claims, but does not lead toward eligibility. The server is recited at a high level of generality and merely adding that a server is used to perform the steps does not integrate the abstract idea into a practical application or provide an inventive concept.
Claim 14 recites “utilize a token validation algorithm to determine whether the redaction token is valid or invalid; and further base said facilitate delivery of the unredacted version of the particular model element unredacted version of the particular model element on an indication from the token validation algorithm that the redaction token is valid”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract. It is also noted that the algorithm is recited generically and there is no detail regarding the algorithm or how it is implemented.
Claim 18 recites “each of the engineering teams has a respective security client;
the processing circuitry is configured determine whether the request complies with the one or more first security requirements independently of the security client of the first engineering team; and to facilitate delivery of the unredacted version of the particular model element, the processing circuitry is configured to send an indication of the request to the security client of the first engineering team for determination, by the security client of the first engineering team, of whether the request fulfills the one or more second security requirements”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract. The “security client” is recited at a high level of generality and merely reciting the security client to perform these steps does not integrate the abstract idea into a practical application or provide an inventive concept. See specification at [0039]. The security client is described generically with little technical detail.
Claim 20 recites “wherein, for each engineering team, the security client is configured to act as a broker by: communicating with the server to send and receive requests for model elements; communicating with the server to sending and receiving model elements; and storing third party tokens for accessing redacted versions of model elements of others of the engineering teams”, which specifies further steps related to determining users’ access to model elements, but does not make the claims any less abstract. The server is recited at a high level of generality and merely adding that a server is used to perform the steps does not integrate the abstract idea into a practical application or provide an inventive concept. The “security client” is recited at a high level of generality and merely reciting the security client to perform these steps does not integrate the abstract idea into a practical application or provide an inventive concept. The “security client” is recited at a high level of generality and merely reciting the security client to perform these steps does not integrate the abstract idea into a practical application or provide an inventive concept. See specification at [0039]. The security client is described generically with little technical detail.
The claims do not provide any new additional limitations or meaningful limits beyond abstract idea that are not addressed above in the independent claims therefore, they do not integrate the abstract idea into a practical application nor do they provide significantly more to the abstract idea. Thus, after considering all claim elements, both individually and as a whole, it has been determined that the claims do not integrate the judicial exception into a practical application or provide an inventive concept. Therefore, Claims 2-12 and 14-20 are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 1-6, 8-10, 12-16, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ognev et al. (Pub. No. US 2021/0357550 A1) in view of Skinner et al. (Patent No. US 10,347,293 B1).
In regards to Claim 1 and 13, Ognev discloses:
A method/system for sharing a digital model, comprising:
storing in memory at least metadata of a digital model of a system, wherein the digital model includes a plurality of discrete subsystems representing different functions of the system, each subsystem including a plurality of discrete model elements, and design responsibility for different ones of the model elements is assigned to different ones of a plurality of engineering teams; ([0034], stored in memory; Abstract; [0015], metadata is used to determine which elements are un-shareable (redactable); [0035], example of a system being modeled (airplane); [0019], the model include subsystems, such has engine have discrete model elements (see also [0046]; [0063], the model includes multiple subsystems, such has engine, electrical system, seat, fuselage, etc. that represent different functions, these subsystems have discrete model elements (“…specific type of engineering element (e.g., fuselage body, speakers, etc.), part number, part type,…), items such as parts would be engineering element included in the subsystems); [0018]; different engineering teams (vendors) are responsible for different subsystems (and that subsystems model elements))
Additionally, Ognev discloses that user on different engineering teams have access to different redacted or unredacted versions of the model based on security policies associated with teams ([0016]; [0046]; [0051], entities have access to different versions of the model (which includes access to the model elements controlled by multiple responsible entities/teams), based on access rights (the “unrestricted” version of the model is the version that has redacted elements); [0045], elements belonging to the team (vendor) can be redacted from the model, so that a non-team member (such as a user from the internal organization/model maker) based on security policies (“…the vendor 220 may need to keep some portions of the unrestricted version 144 hidden from the model maker…tag those designs as proprietary, confidential, or IP-related…” (see also [0002]; [0020], additionally examples of security policies requiring redaction))
Ognev discloses the ability to restrict which content of the model’s system collaborators can access (redacted or unredacted elements), as shown above. Ognev does not explicitly disclose the use of tokens along with a request to access a particular model element to determine if a user will receive a particular model element in a redacted version or an unredacted version. However, Skinner teaches:
receiving, from each of a first user and a second user that are not part of a first team of the plurality of teams, respective requests to access a particular element of a particular subsystem, wherein design responsibility for the particular model element is assigned to the first team, and the particular element includes at least one redaction implemented according to a security policy of the first team; (column 7, lines 36-42, users select thumbnails to access content/files (request for a particular element); column 7, lines 44-50, boards may be associated with teams (or tenant accounts or organizations), boards represent collections of content/files uploaded by the team (i.e. content/files for which the team is responsible), in the context of Skinner, the boards/collections belonging to each team/tenant would be comparable to a subsystem (a subset of the content/files on the content sharing system); column 14, lines 25-54, determination of supplying a redacted or unredacted version can be based on whether or not a requestor is on the same team or a different team/organization as the content owner (“For example, some embodiments may automatically provide access to unredacted versions of content items to members on the same team or to users in the same tenant organization or to users on the same or a specified local area network or virtual private network, while blocking access or providing access to redacted versions to users requesting content that do not satisfy these criteria.”, not satisfying the criteria indicates a user NOT on the same team/organization; column 8, lines 20-24, content can include images of CAD files (computer aided design), one of ordinary skill in the art would recognize that CAD can be used for modeling and engineering projects; column 8, lines 7-19; Claim 16, demonstrates a security policy for redaction, “…each tenant having a respective policy specifying tenant-specific criteria for classifying text as confidential…”, tenant accounts including teams (see column 7, lines 34-35, “…tenants including those teams or tenants for which the user is an employee…”), the system/method of Skinner includes different access levels to different groups of users, including to tenant accounts, which include multiple teams (see also column 10, lines 27-41 & 56-66; column 7, lines 34-36; column 7, line 66-colum 8, line 2; etc.), one of ordinary skill in the art would recognize that the system/method of Skinner can be used by multiple users (including multiple users outside of the team), Skinner does not limit the use of the system/method to a single access request or to requests by a single user (nor would one of ordinary skill in the art interpret it as such))
based on the request from the first user lacking a redaction token corresponding to the at least one redaction, facilitating delivery of a redacted version of the particular element to the first user that includes the at least one redaction; (column 5, lines 29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-20, as described in subsequent step, below, includes processes for both facilitating delivery of redacted and unredacted versions based on lack of a redaction token or inclusion of a redaction token)
based on the request from the first user including the redaction token, facilitating delivery of an unredacted version of the particular element to the second user (column 5, lines 29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-28, users are provided access to reacted or unredacted versions based on permissions associated with the user or user account, redacted or unredacted versions may be based on user criteria such as permissions, credentials, team affiliation, tenant affiliation, levels of access, roles, etc., these criteria are associated with the request (credentials are used for authentication and are associated with a user account that includes permissions, roles, etc.), for example, which version is supplied can depend on whether the user supplied the appropriate credentials, the credentials act as a “redaction token” an unredacted version is supplied, if the appropriate credentials are not supplied (request lacking the redaction token), a redacted version is supplied (modified version refer to redacted/obfuscated version (credentials are used to authenticate a user, such as (but not limited to) a username and password for a user account, that account is then used to determine permissions and related data for requests for content access, therefore the credentials (and other account data) act as tokens that designates whether a user has access to redacted or unredacted versions), if the appropriate credentials are supplied (request including the redaction token), see also column 12, lines 18-20; etc., the system/method of Skinner includes different access levels to different groups of users, including to tenant accounts, which include multiple teams (see also column 10, lines 27-41 & 56-66; column 7, lines 34-36; column 7, line 66-colum 8, line 2; etc.), one of ordinary skill in the art would recognize that the system/method of Skinner can be used by multiple users (including multiple users outside of the team), Skinner does not limit the use of the system/method to a single access request or to requests by a single user (nor would one of ordinary skill in the art interpret it as such), additionally, one of ordinary skill in the art would recognize that requests by different users would include the different access permissions and tokens for those users when applying the above steps for providing access to reacted or unredacted versions of content based on tokens for different users with and without tokens)
wherein at least said receiving step and facilitating delivery steps are performed by a security server (Fig. 2 (at least 86-96); column 5, lines 29-33; column 17, lines 2-28, requests are made to remote servers, the process of requesting content includes the process of determining authorization and permissions (tokens) for facilitating the correct content to a user, this process performed with a remote server would represent a “security server” as recited in Applicant’s claims)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included receiving, from each of a first user and a second user that are not part of a first team of the plurality of teams, respective requests to access a particular element of a particular subsystem, wherein design responsibility for the particular model element is assigned to the first team, and the particular element includes at least one redaction implemented according to a security policy of the first team; based on the request from the first user lacking a redaction token corresponding to the at least one redaction, facilitating delivery of a redacted version of the particular element to the first user that includes the at least one redaction; based on the request from the first user including the redaction token, facilitating delivery of an unredacted version of the particular element to the second user, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claims 2 and 14, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
utilizing a token validation algorithm to determine whether the redaction token is valid or invalid; (column 7, lines 27-36, includes authentication of a user’s credentials (representing a redaction token, as described above) “…such as a salted cryptographic hash of a user password...”, demonstrating a validation (authentication) algorithm)
said facilitating delivery of the unredacted version of the particular model element is further based on the token validation algorithm indicating that the redaction token is valid (column 13, lines 14-20, access to versions of the model is dependent upon user authentication (credentials), see also column 5, lines29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-20, as provided in the parent claims to describe the use of credentials and permissions to access the different model versions)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included said facilitating delivery of the unredacted version of the particular model element is further based on the token validation algorithm indicating that the redaction token is valid, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claims 3 and 15, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
receiving, from an administrative user associated with the first engineering team, an indication of a plurality of discrete digital redactions that correspond to different model elements of the particular subsystem; and associating different redaction tokens with each of the discrete redactions (column 14, lines 25-544-36, administrators are provided data related to user risk and can dynamically adjust permissions related to content access, different redaction policies can be set for discrete elements (discrete elements being represented by a content item at a specific URL, “…this may include responding to the above-described risk related alerts to de-permission users automatically. Some embodiments may determine whether a request for a content item at a given URL should be serviced with a more heavily redacted version, a less heavily redacted version, or an unredacted version of a content item based upon permissions associated with a request…”), this is performed in response to alerts received by administrators who dynamically adjust permissions, permissions associated with a request can be individually tailored to the content item at the specific URL (i.e. each content item at a different URL could have a different redaction permissions); see also column 5, lines29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-20, as provided in the parent claims to describe the use of credentials and permissions to access the different model versions; column 10, lines 63-64, “…access may be granted with relatively high granularity to individual units of content…”)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included receiving, from an administrative user associated with the first engineering team, an indication of a plurality of discrete digital redactions that correspond to different model elements of the particular subsystem and associating different redaction tokens with each of the discrete redactions, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claim 4, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
wherein said utilizing the token validation algorithm comprises: comparing the received redaction token, or a value derived from the received redaction token, with a master redaction token corresponding to the at least one redaction, or a value derived from the master redaction token; and determining whether the received redaction token is validated based on the comparison (column 7, lines 27-36, the repository includes user account records which include user credentials by which a user is authenticated (such as ser identifier, password, and other data), this would represent a master redaction token that would be used to authenticate a user (and thus provide the permissions they need for content access), for example, when a user enters their credentials (user identifier and password) it would be compared to the user identifier and password in the account record in the repository to authenticate the user; see also column 5, lines29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-20, as provided in the parent claims to describe the use of credentials and permissions to access the different model versions)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included wherein said utilizing the token validation algorithm comprises: comparing the received redaction token, or a value derived from the received redaction token, with a master redaction token corresponding to the at least one redaction, or a value derived from the master redaction token and determining whether the received redaction token is validated based on the comparison, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claims 5 and 16, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
receiving a request from the first or the second user to access an additional model element of the particular subsystem; and facilitating delivery of the additional model element (column 5, lines 33-36, user can make multiple request, “…in a user account…may include…identifiers of such an account so that shared content or access requests may be organized by account…”; column 5, lines29-33; column 7, lines 27-36; column 14, lines 25-54; column 17, lines 2-20, the process for requesting and receiving access would be performed in the same manner as described above, in the parent claims, for each request).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included receiving a request from the first or the second user to access an additional model element of the particular subsystem and facilitating delivery of the additional model element, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
Although Ognev/Skinner does not explicitly state that receiving the second requested element is non-redacted and that facilitating delivery does not require receipt of a redaction token, Skinner does teach the ability to adjust risk based on users previously requesting content (column 13, lines 43-67, risk is determined for users and can include weights applied to certain attributes or criteria, one example is providing a low weight to users who have accessed content shared by the first user (team) before).
As risk is directly related to permissions for redacted or unredacted content, one of ordinary skill in the art would recognize that this low weight signifies less risk and higher trust in users who have accessed a first users/teams content before and thus would provide reason to trust that requesting user and not require a token (see also column 14, lines 4-24, permissions can be updated based on the risk, the example provided is the removal of permissions for high risk and increasing of confidential data, although not explicitly stated, this would demonstrate that permissions could also be granted (increased) for low risk and/or amount of confidential information decreased for a user/team). Therefore, It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that the system of Ognev/Skinner would include the ability to reduce required credentials based on users’ previously accessing content and providing less risk, as outlined above (see at least Skinner, column 13, lines 43-67; column 14, lines 4-24), and the references demonstrate the necessary level of skill.
In regards to Claim 6, Ognev discloses:
each engineering team has one or more first security requirements that must be fulfilled to access its model elements; and said facilitating steps are further based on the request from the user fulfilling the one or more security requirements of the first engineering team ([0020]; [0046], includes examples of security requirements, one example being that the other team/organization may access some elements if it is in the same country (security requirements related to export control laws); [0035], an organization can set controls against sharing elements externally)
In regards to Claim 8, Ognev discloses:
the security server performs said storing step; ([0048], servers may be used for storage; [0034], remote servers may be used to expose model version to user over an internet connection, indicating that the server is used for requests and facilitating delivery)
Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
the method includes the security server validating the redaction token, and based on a successful validation, sending an indication of the request to a security client of the first engineering team to facilitate determination, by the security client, of whether the request fulfills the one or more second security requirements (column 14, lines 25-54, an access control module (security client) is used to demine whether the request fulfills a tenant policy and demine what version to provide to the requester)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included the method includes the security server validating the redaction token, and based on a successful validation, sending an indication of the request to a security client of the first engineering team to facilitate determination, by the security client, of whether the request fulfills the one or more second security requirements, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claim 9, Ognev discloses:
wherein the one or more security requirements include at least one of:
a requirement that an IP address of a computing device that the request received from is not a blacklisted IP address;
a requirement that the computing device is not located in an unauthorized geographic territory; ([0046], access to elements can be based on geographic location, for example in the same country, access provided to external organizations is based on the organization not posing a risk based on the country in which they exist, this would indicate an authorized geographic location, other countries represent an unauthorized location and are not granted access to redacted elements)
a requirement that a static device identifier of the computing device is not blacklisted.
In regards to Claim 10, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
wherein the one or more security requirements include at least one of:
a requirement that the user is not part of a user group that the first engineering team has prohibited from accessing unredacted model elements of the first engineering team; (column 8, lines 7-19, patterns are applied to teams to determine what content is redacted/blacklisted, indicating content that a team has been prohibited from accessing)
a requirement that the redaction token has not been used more than a predefined number of permitted times
In regards to Claim 12, Ognev discloses:
wherein: the security server performs said storing step; ([0048], servers may be used for storage; [0034], remote servers may be used to expose model version to user over an internet connection, indicating that the server is used for requests and facilitating delivery)
said facilitating delivery of the redacted version of the particular model element comprises the security server obtaining the redacted version from its own storage, and sending the redacted version to the user; ([0048], servers may be used for storage; [0034], remote servers may be used to expose model version to user over an internet connection, indicating that the server is used for requests and facilitating delivery, including redacted/unrestricted versions)
Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
said facilitating delivery of the unredacted version of the particular model element to the user comprises the security server obtaining the unredacted version from the first engineering team in response to the request, and sending the unredacted version to the user after it is received from the first engineering team (column 16, line 65-column 17, line 28, a first user/team can create a URL to share, requests by a second user/team are made by the URL, the URL is used instead of uploading to the central service demonstrating that the content is retrieved directly from the first user/team in response to the request)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included said facilitating delivery of the unredacted version of the particular model element to the user comprises the security server obtaining the unredacted version from the first engineering team in response to the request, and sending the unredacted version to the user after it is received from the first engineering team, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claim 18, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
each of the engineering teams has a respective security client; (column 14, lines 25-54, an access control module (security client) is used to demine whether the request fulfills a tenant policy and demine what version to provide to the requester, the policy is associated with a tenant, therefore the access control module would be a unique security client for each policy)
the processing circuitry is configured determine whether the request complies with the one or more first security requirements independently of the security client of the first engineering team (column 14, lines 25-54, an access control module (security client) is used to demine whether the request fulfills a tenant policy and demine what version to provide to the requester, this is done based on the permissions associated with the request, user has permissions represents a first security requirement that is performed before sending to the security client (access control module))
to facilitate delivery of the unredacted version of the particular model element, the processing circuitry is configured to send an indication of the request to the security client of the first engineering team for determination, by the security client of the first engineering team, of whether the request fulfills the one or more second security requirements (column 14, lines 25-54, after permission is determined, it is then sent to the access control module to determine further requirements to determine what versions should be provided (second security requirement))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included each of the engineering teams has a respective security client and the processing circuitry is configured determine whether the request complies with the one or more first security requirements independently of the security client of the first engineering team to facilitate delivery of the unredacted version of the particular model element, the processing circuitry is configured to send an indication of the request to the security client of the first engineering team for determination, by the security client of the first engineering team, of whether the request fulfills the one or more second security requirements, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
In regards to Claim 19, Ognev discloses:
wherein the first security requirements or second security requirements include at least one of:
a requirement that an IP address of a computing device that the request received from is not a blacklisted IP address;
a requirement that the computing device is not located in an unauthorized geographic territory; ([0046], access to elements can be based on geographic location, for example in the same country, access provided to external organizations is based on the organization not posing a risk based on the country in which they exist, this would indicate an authorized geographic location, other countries represent an unauthorized location and are not granted access to redacted elements)
a requirement that a static device identifier of the computing device is not blacklisted;
a requirement that the user is not part of a user group that the first engineering team has prohibited from accessing unredacted model elements of the first engineering team;
a requirement that the redaction token has not been used more than a predefined number of permitted times; and
a requirement that the particular model element is not flagged for inclusion in a patent application that has not yet been filed.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ognev in view of Skinner in further view of Harpur et al. (Pub. No. US 2016/0173431 A1).
In regards to Claims 7 and 17, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
the one or more security requirements of the first engineering team include one or more first security requirements and one or more second security requirements that differ from the one or more first security requirements;
compliance of the request with the one or more second security requirements of the first engineering team is a prerequisite for delivery of the unredacted version, but not the redacted version, of the particular model element (column 14, lines 43-48, provides different security requirements that determines that a request gets only an unredacted version, such as on the same or a specified local area network or virtual private network)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included compliance of the request with the one or more second security requirements of the first engineering team is a prerequisite for delivery of the unredacted version, but not the redacted version, of the particular model element, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
Ognev/Skinner discloses the above system/method for providing redacted and/or unredacted versions of models to different teams including. Ognev/Skinner does not explicitly disclose access to both the redacted and unredacted versions, but Harpur teaches:
compliance of the request with the one or more first security requirements of the first engineering team is a prerequisite for delivery of the redacted version and the unredacted version of the particular model element; ([0046], user gets a redacted message and can also access the unredacted message; [0050]; [0051], uses security requirements to determine if the users has access to both version, including unredacted original message (content))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev/Skinner so as to have included compliance of the request with the one or more first security requirements of the first engineering team is a prerequisite for delivery of the redacted version and the unredacted version of the particular model element, as taught by Harpur in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30; Harpur, [0046]; [0050]; [0051]).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ognev in view of Skinner in further view of O’Malley (Patent No. US 12,094,018 B1).
In regards to Claim 11, Ognev/Skinner discloses the above system/method for providing redacted or unredacted versions of models to different teams including rejecting a request for an unredacted version of the particular model element [based on security policies]. Ognev/Skinner does not explicitly disclose access and redaction-based inclusion in an unfiled patent application , but O’Malley teaches:
[preventing access to an unredacted] based on the particular model element being flagged for inclusion in a patent application that has not yet been filed (column 407, lines 40-58, files shared with other collaborating users (“…options to present to fellow internal patent attorneys for their input…”) are redacted (“…redacts any client critical information…”) based on the information being included in a patent application that has not yet been filed (“…in a particular application currently being prepared (but not filed yet)… (3) generate a list of options to present to fellow internal patent attorneys for their input…”))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev/Skinner so as to have included [preventing access to an unredacted] based on the particular model element being flagged for inclusion in a patent application that has not yet been filed, as taught by O’Malley in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ognev in view of Skinner in further view of Dave et al. (Pub. No. US 2014/0096199 A1).
In regards to Claim 20, Ognev discloses the above system/method for providing redacted or unredacted versions of models to different teams. Ognev does not explicitly disclose, but Skinner teaches:
a security client for each engineering team (column 14, lines 25-54, an access control module (security client) is used to demine whether the request fulfills a tenant policy and demine what version to provide to the requester, the policy is associated with a tenant, therefore the access control module would be a unique security client for each policy)
storing third party tokens for accessing redacted versions of model elements of others of the engineering teams (column 17, lines 1-28, credentials are associated with appropriate teams, tenants, etc., this indicates that multiple teams have credential/accounts/permissions, therefore the team used as the first team in the examples throughout the reference would also have credentials for accessing other teams, representing the third-party tokens)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev so as to have included a security client for each engineering team and storing third party tokens for accessing redacted versions of model elements of others of the engineering teams, as taught by Skinner in order to ensure that confidential information (such as intellectual property, trade secrets, legally protected data, etc.) does not leak to unauthorized users (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30).
Ognev/Skinner discloses the above system/method for providing elements (assets) to users based on requests and security policies. Ognev/Skinner does not explicitly disclose the security clients being used as brokers, however, Dave teaches:
a security client is configured to act as a broker by:
communicating with the server to send and receive requests for model elements;
communicating with the server to sending and receiving model elements; ([0043]; [0044]; [0064], etc., a security server (security client) can be used as a broker to send and receive data (comparable to model elements) and send and receive requests for data (can send invitations representing requests), the security server also uses a=n authentication method similar to Ognev/Skinner; Fig. 2, data access module is part of the security server)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the system of Ognev/Skinner so as to have included a security client is configured to act as a broker by communicating with the server to send and receive requests for model elements and communicating with the server to sending and receiving model elements, as taught by Dave in order to ensure that users only have access to data to which they have authorization (Ognev, at least Abstract; [0020]; [0021]; [0044]; Skinner, at least column 3, lines 11-30; Dave, at least [0064]).
Additional Prior Art Identified but not Relied Upon
Coulman et al. (Pub. No. US 2007/0174207 A1). Discloses a collaborative work environment/system and providing the ability of different remote collaborators (teams/organizations/entities) to access global or partial information (see at least Abstract; [0016]-[0022]; [0025]; [0029]).
Frielingsdorf et al. (WO 2018011775 A1). Discloses authentication of users for accessing data using tokens on third party servers (see at least Abstract; [0012]).
Gustoff et al. (Pub. No. US 2023/0195934 A1). Discloses request for data and providing redacted or unredacted versions-based access rights of the user (see at least [0047]).
Hadfield et al. (Patent No. US 10,574,729 B2). Discloses a system/method for cross platform document sharing among multiple user systems, including security policies that can redact information based on user permissions and policies (see at least column 4, line 1-column 5, line 24; column 6, lines 1-11; column 7/8, items 5-7; column 9, lines 4-6; Claims 7, 7, 10, 11, & 22-26).
Jayapalan et al. (Patent No. US 10789385 B1). Discloses request for data and providing redacted or unredacted versions-based access rights of the user (see at least column 4, lines 1-24).
Response to Arguments
Applicant’s arguments filed 1/2/2026 have been fully considered but they are not persuasive.
I. Rejection of Claims under 35 U.S.C. §101:
Step 2A, Prong 1: Applicant argues that the “claim limitations relate to a security server providing a technical solution to the technical challenge of maintaining data security of model elements in a collaborative design environment. There is no way that a human could ever perform the features of claim 1 in their mind, because a human can never be a "security server" and the human mind cannot control access to digital models of a system.” As explained in the above rejections, the “security server” merely represents a generic, general-purpose computer used for performing the steps of the claims. Applicant has not demonstrated how/why the security server would be significant in “providing a technical solution to the technical challenge of maintaining data security of model elements in a collaborative design environment” in a meaningful manner, nor does Applicant describe or explain the alleged technical problem and/or how the alleged solution is achieved. Merely labelling the server as a “security server” does not inherently provide particular functionality to the server beyond what is in the claims or disclosure.
The above rejections do not rely on the abstract idea of mental steps at this time, therefore Applicant’s remarks regarding Mental steps are moot.
Step 2A, Prong 2: As above, merely reciting that the claims are performed using hardware does not necessarily practical application. Applicant fails to identify the alleged practical application and/or how the recited technology would integrate the claims into that practical application in a meaningful manner.
The recited server is merely a generic tool for performing the claims steps (see above rejection for further detail). Applicant has not provided any evidence to demonstrate the alleged functionality [and] technical improvements provided by these features. Applicant has not identified the alleged technical improvements and has not explained how/why the functionality of the server would be significant. As explained in the above rejection, the server is merely used as a tool to perform the claim steps, nothing in the claims demonstrates that the server provides any functionality beyond its normal functions or demonstrates a special-purpose computer would be required to perform steps such as receiving data, determining if a token is present, and transmitting data (facilitating delivery) based on that determination. Receiving, analyzing, and transmitting data are recognized generic computer functions.
In regards to Applicant’s Bascom argument’s, Applicant fails to provide any explanation, comparison, reasoning, etc. to demonstrate why the characteristics of Applicant’s claims would be comparable to the findings of Bascom. Applicant merely asserts that they are similar, but does not compare the fact patterns of Bascom to the fact patterns claimed invention.
Step 2B: Applicant fails to provide any background and/or evidence to demonstrate the alleged problems and improvements. Applicant provides no arguments or support to demonstrate how/why the claimed invention would address the alleged problem to produce the alleged technical improvement in a meaningful manner beyond the identified abstract ideas (does not explain or demonstrate how “significantly more” is achieved).
See MPEP 2106.05(a), Improvements to the Functioning of a Computer or To Any Other Technology or Technical Field (“If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology.”).
II. Rejection of Claims under 35 U.S.C. §103:
The tokens in Skinner that Applicant is referring to in Applicant’s remarks are not the tokens being applied to the claims. The material in Skinner that reads on the “tokens” in Applicant’s claims are the credentials of the user (authorizations, permissions, other data used to identify a user’s access rights to content), as identified and explained in the claim rejections. Although there are other items labeled as tokens (OCR’d text), these are not addressed or referenced in the claim rejections, and the rejection citations point to the material of Skinner that is being read as “redaction tokens”.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAUN D SENSENIG whose telephone number is (571)270-5393. The examiner can normally be reached M-F: 10:00am-4:00pm.
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, Lynda Jasmin can be reached at 571-272-6872. 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.
/S.D.S/Examiner, Art Unit 3629 May 10, 2026
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights